Credit wagering system and method of use with loan and warrantying

ABSTRACT

A system and method providing, in some embodiments, at least partially automated processing for warrantying, settling, requesting, approving, processing, advancing, collecting, and/or managing of credit provided for use in wager gaming and related activities, including, in some instances, one or more of loan transactions, loan warrantying services, operator receivable participation interest, receivable purchase associate with patron&#39;s repayment of the receivable, third-party provision of advances to an operator patron limited for use within the operator property or properties for designated gaming activities, associated fees, activity tracking, activity reporting, credit approval throttling, fund advancement throttling, credit account packaging and transfer, automated collections, and responsible wager gaming.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of applicant's prior U.S. patentapplication Ser. No. 17/023,179 entitled “Credit Wagering System AndMethod Of Use With Loan And Warrantying” filed Sep. 16, 2020, whichclaims priority through applicant's prior U.S. patent application Ser.No. 16,523,710 entitled “Wager Credit Management System And Method OfUse” filed Jul. 26, 2019, which claims priority through the applicant'sprior provisional patent applications as follows:

1. Credit Wagering System With Loan And Factoring And Method Of Use,application No. 62/703,781, filed Jul. 26, 2018;

2. Credit Wagering System With Loan And Factoring And Method Of Use,application No. 62/711,356, filed Jul. 27, 2018; and

3. Credit Wagering System With Loan And Factoring And Method Of Use,application No. 62/814,407, filed Mar. 6, 2019; all of whichcontinuation-in-part and provisional applications are herebyincorporated by reference in their entirety, provided that if any ofthese prior applications are in any way inconsistent with the presentapplication (including without limitation any limiting aspects), thepresent application will prevail. The present application further claimspriority through the applicant's additional prior provisional patentapplications as follows:

1. Wagering Account Pooling System and Method of Use, application No.62/901,148, filed Sep. 16, 2019; and

2. Remote Wagering Credit Administration and Method of Use, applicationNo. 63/035,462, filed Jun. 5, 2020; both of which additional provisionalapplications are hereby incorporated by reference in their entirety,provided that if any of these prior applications are in any wayinconsistent with the present application (including without limitationany limiting aspects), the present application will prevail.

COPYRIGHT

A portion of the disclosure of this patent document contains or maycontain material subject to copyright protection. The copyright ownerhas no objection to the photocopy reproduction of the patent document orthe patent disclosure in exactly the form it appears in the Patent andTrademark Office patent file or records, but otherwise reserves allcopyright rights.

TECHNICAL FIELD

The technology of the present application relates to a credit wagersystem and method of use, and more particularly in varying embodimentsto a credit wager system and method of use with loan and/or warrantyingfor the warrantying, settling, requesting, approving, processing, and/ormanaging of credit provided for use in wager gaming and relatedactivities, including one or more of loan transactions, loan warrantyingservices, operator receivable participation interest, receivablepurchase associate with patron's repayment of the receivable,third-party provision of advances to an operator patron limited for usewithin the operator property or properties for designated gamingactivities, associated fees, activity tracking, activity reporting,credit approval throttling, fund advancement throttling, credit accountpackaging and transfer, automated collections, and responsible wagergaming.

CERTAIN ASPECTS OF THE BACKGROUND AND OF SOME OF APPLICANT'S INVENTIVECONTRIBUTIONS

Traditionally, placing wagers on gaming devices has dominantly involvedsubmitting tangible currency such as bills and coins at the time thewagers were placed. If a player had no cash or coins, the player had tostop playing, or otherwise temporarily leave the gaming area to obtainadditional currency. Operator (which is defined herein to include anywager gaming operator or provider, including, but not limited to,physical casinos, card clubs, online gaming providers, mobile gamingproviders, sports book operators, fantasy sports providers, and thelike) credit such as cashing checks and issuing markers developed asways for players to get cash, on credit, to continue playing. Theproblems with traditional operator credit have long been many.

For example, the player, once given the cash issued on credit, wouldhave to physically take the money to the gaming device to play. This hasallowed the player to take the cash and not use it to play at the gamingdevice. The player could simply pocket the cash and walk out of thecasino. The casino has often born the risk, associated costs, or both ofcollecting, from the player, credit receivable obligations if the playerfailed to repay a marker, if the player's check bounced, or both.Further problems for casinos include delays associated with handling andmanaging traditional credit, such as cash flow shortages resulting fromthe period of time such credit remained uncollected.

At the same time, the prominent use of cash at one or more phases of thegaming process has also long presented significant problems. Forexample, the carrying of cash to and from the casino sometimes increasesthe occurrence of theft from players, which has resulted in one or moreof reducing the quality of the casino experience for patrons, increasingcosts to the casino for liability coverage and security, reducing thenumber and frequency of return player visits, and negatively impactingthe reputation of the casino with respect to potential customerperception, community perception, or both. This had one or more of arevenue impact on the casino, a financial and psychological impact onplayers, and a negative impact on the ability of casinos to foster apositive community perception that might have assisted in helping topromote pro-casino local, state, and national laws and regulations, aswell as pro-casino zoning decisions.

In addition, the absence of easily obtained wager credit has typicallyplaced an added burden on players to procure and manage their cashcarry. Players have had to first consider when and where to obtain cash,and also consider their potential stake for the relevant gaming periodto avoid having to return to a cash provider. The cash carry also hadhad to be managed by the player while engaged in gaming, including thesubmitting of cash to devices, tables, or sports book, the retrieving ofcash from devices, tables, or sports book, and the continued need tomonitor cash not being played to avoid loss, such as by dropping billsor coins. This overhead sometimes resulted in a degraded playerexperience, along with an increase in player anxiety due to the amountof cash carried, the risk of losing a portion of the cash, or both.

For communities, the cash nature of the casino gaming environment hassometimes placed an increased burden on community services, such as thedemands placed on law enforcement, the courts, and other social andhealth care service providers. For example, with the level of crimeresulting, at least in part, from the presence of cash—often massiveamounts—inside and outside the casino, the increased presence of police,both for crime prevention and for response to criminal activity, hasoften increased the overall cost of services, which often impacts boththe burden on taxpayers as well as the availability of such resources tofocus on other more pressing criminal activity. Similarly, courts andother social and health care services have been impacted, facing anincreased caseload as the number of arrests have increased and otherrelated consequences of crime, including diversion and consumption ofcasino resources, commensurately increase as well.

The absence of easy player access to wager credit and the resultinginvolvement of large quantities of cash in the traditional gamingexperience also has long-burdened the casino operator. Casinos often hadto handle and manage very large cash drops in order to ensure they couldcash out players, which involved various labor costs, including, forexample, costs associated with moving cash to and from the casino, aswell as around the casino and among properties. A further disadvantagehas long been the increased risk of casino theft, along with theresulting impact on the cost of security to prevent such theft, bothduring the transport of cash to and from the casino, as well as withinthe casino.

Consequently, casinos and card clubs have long been vulnerable to moneylaundering and other financial crimes because of the nature of theseoperations. These gaming institutions are fast-paced, cash-intensivebusinesses that often provide a broad array of financial products andservices, some of which are similar to those provided by financialdepository institutions and money services businesses. Moreover, gaminginstitutions serve a diverse and transient customer base about whichthey often have relatively little knowledge. And, players have oftenstructured transactions to avoid certain reporting thresholds.

Country- and state-specific regulatory requirements also have directlyimpacted operator's ability to extend and the burden of managing credit.For example, in the U.S., casinos became subject to anti-moneylaundering regulations promulgated under the Bank Secrecy Act (BSA) in1985. Federal law requires casinos to report currency transactions overcertain threshold amounts, such as $10,000, conducted by, or on behalfof, one person, as well as multiple currency transactions that aggregateto over certain legislated threshold amounts in a single day. Thesetransactions are reported on reports, such as, for example, a CurrencyTransaction Report by Casinos (CTRC) form. In addition, casinos arerequired to report suspicious transactions (or patterns of transactions)conducted or attempted by, at or through the gaming establishment. Theselaws were passed to safeguard against money laundering and otherfinancial crimes. Historically, it was both labor intensive and systemsintensive to track, retrieve, analyze, and report such transactions tothe extent it was possible to do so reliably.

To comply with this U.S. law, operators must not only use all availableinformation to detect and report the transactions themselves, but alsoobtain and include the personal identification information about theindividual conducting the transaction such as a social security number,driver's license, or other government issued document, in the filedreport. This burdensome requirement applies whether individualsconducting the transactions are wagering on behalf of themselves orsomeone else.

Historically, it also has been difficult for operators to detectsuspicious activity and CTRC report triggering events. Even when suchactivity and events have been detected, it has been difficult and oftenmanually intensive to collect evidence surrounding such events, collectthe necessary player-related information, prepare the required reports,and file the required reports with the casino records-keeping system andwith an applicable regulatory agency. Often such challenges haveresulted in reports not being filed, which in certain cases resulted insignificant legal and financial consequences for casinos failing to useall available information and file such reports.

For example, in the U.S., nearly half of the filings made by operatorsreported suspicious activities are characterized as “structuring” or“minimal” gaming. These activities involve chip, jackpot, and tokenredemptions that customers may have structured to avoid currencytransaction reporting requirements. Under U.S. federal law it has longbeen a crime to break up transactions into smaller amounts for thepurpose of evading the reporting requirement, and detection of thisactivity can lead to a required report from the operator to thegovernment.

A structured transaction can include, for example, situations such asthe following. The player opens a line of credit with the operator for$27,000. The player knows the operator will be required to file aCurrency Transaction Report if the player makes a payment with over$10,000 in currency on a single day. To evade a Currency TransactionReport being filed, the player makes $9,000 payments on the line ofcredit over different gaming days. Tracking this type of activity toreport it in compliance with regulatory requirements is oftenchallenging and costly.

With the requirement of using all available information to detect andreport, significant burdens were placed on systems not designed for suchoptimized data collection and analysis, which could result in increasedand inefficient bandwidth usage, excessive data storage demands,wasteful proliferation of computing devices, unsynchronized data anddata integrity issues, and the like.

The Applicant further believes it has discovered certain disadvantagesand drawbacks of gaming even when implemented with credit lines asdescribed above. Costs are incurred in association with determiningwhether to grant a credit line to a player; these costs may take theform of a fee for a credit report, the time and effort of operatoremployees to process credit applications, the time and effort involvedin an on-the-spot decision by an employee to grant a credit line withoutan advance application, and even the expense of establishing andmaintaining an electronic system that can make credit determinationswithout employee involvement. For these and other reasons, the operatoroften does not want to be in the business of evaluating, providing, andcarrying massive credit or be involved in any way with efforts to obtainrepayment, including to avoid unpleasantness between the casino and itscustomers. Operators are therefore often unwilling or unable to serve asa source of funds for players in connection with granting credit lines,particularly on a large scale as the number and type of playersrequesting credit lines increases, as has long been occurring in thewager gaming industry.

For many years, operator's also have faced increased pressure to foster,support, and enforce responsible gaming. Many operators have takenproactive approaches in trying to address responsible gaming, whichapproaches have often proven to be costly, limited in theireffectiveness, or both. For example, in many jurisdictions, both in theUnited States and abroad, such as in Australia, cash dispensingtechnologies such as automated teller machines are required to belocated at a minimum distance from the gaming floor. Among other things,regulators hoped that, by requiring players to leave the gaming floorwhen in need of advancing funds, they would be less likely to engage inirresponsible gaming behavior, having to walk away from the gaming floorfor some period of time. This approach to try to provide moreresponsible gaming has many disadvantages, including disrupting theresponsible player's gaming experience, reducing cash velocity even whensuch reduction is not necessary or useful, requiring players to leave aparticular machine to which they have a developed an affinity, andquestionable efficacy, as the player is not prevented from returning andgambling irresponsibly. In addition, many approaches to encouraging andenforcing responsible gaming employ the personal involvement of casinopersonnel, which can be costly, subjective, embarrassing to the player,and inefficient.

With respect to the securing and administering credit for purposes ofusing such credit to place wagers in the context of gaming wastraditionally a complex, inefficient, resource-intensive endeavor forone or more of the player, the operator, and the credit provider.Typically, placing wagers on gaming devices involved submitting tangiblecurrency such as bills and coins at the time the wagers were placed. Ifa player had no cash or coins, the player had to stop playing, orotherwise temporarily leave the gaming area to obtain additionalcurrency. Casino credit such as cashing checks and issuing markersdeveloped as ways for players to get cash, on credit, to continueplaying. The problems with casino credit were many.

The Applicant believes it has discovered certain disadvantages anddrawbacks of cashless gaming even when implemented with credit lines asdescribed above. Costs are incurred in association with determiningwhether to grant a credit line to a player; these costs may take theform of a fee for a credit report, the time and effort of casinoemployees to process credit applications, the time and effort involvedin an on-the-spot decision by an employee to grant a credit line withoutan advance application, and even the expense of establishing andmaintaining an electronic system that can make credit determinationswithout employee involvement.

For the patron, a lack of visibility into, and control over, therequesting of, receiving of, drawing of, and paying back of credit hascontributed to reduced enjoyment of the gaming experience. Thissometimes has included one or more of having to pause gaming activity torequest credit in the absence of sufficient available funds, increasesin stress due to uncertainty as to when paydown payments were due, theamounts due, late payments, the amount of available credit, and thelike. Further, the lack of easily-available access to administration ofone or more of the patron's credit accounts, markers, or the like hasoften contributed to inefficient use of the patron's time, repeatedinteractions with multiple electronic systems, staff, or both, theinability to responsibly and effectively control and direct therequesting of, drawing of, wagering of, and payment of credit lines andmarkers, and players carrying larger amounts of cash to, from, andwithin gaming establishment, leading in turn to other problems withtransporting and carrying such cash, including pickpocketing of gameplayers for example.

In addition, there has traditionally been a separation between bankinginterfaces and interfaces available for making payments againstoutstanding wagering credit line balances. It was typically the casethat multiple transactional steps, procedures, and systems were involvedin even the most basic of payment transactions, creating frustration andinefficiencies for one or more of the parties involved in thetransactions.

Further, the absence of modern processes for quickly identifyingavailable credit and credit offers based on a patron's player clubstatus, their current property location, or both often hinderedoperators and credit providers ability to extend the appropriate amountsof credit in a timely manner to patrons wanting to engage in gaming at aparticular property. Manual processes involved in verifying identityfurther impeded smooth and enjoyable credit administration for one ormore of the operator, credit provider, and patron.

Finally, these historically disjointed processes and systems sufferedfrom a variety of technical disadvantages, including one or more of:

-   slower processing due to the involvement of manual procedures,    multiple system integrations, or both;-   increased processing, increased memory demands, or both due, at    least in part, to data duplication across systems, the need to    retrieve data from external systems for validation, or both;-   reduced security due to increased data transmission activity    resulting, at least in part, from the involvement of multiple    intermediary system stopping points;-   increased network bandwidth usage due to system traffic due to    processes involving, for example, email verifications, file    transfers, fax activity, system integrations, scanning activity, and    the like; and-   patron use inefficiencies including one or more of susceptibility to    user error and frustration relating to complex and multiple    graphical user interfaces, paper submissions, phone verifications,    and staff engagement.

BRIEF SUMMARY OF SOME ASPECTS OF THE DISCLOSURE

The inventors believe that they discovered many of the problems andissues with the prior art discussed in the Certain Aspects sectionabove, including in some embodiments their cumulative problematic effectfor operators, patrons, gaming and financial regulatory authorities, lawenforcement, and social and health care service providers, among others,such as insurers and financing providers. To the end of solving or atleast substantially reducing one or more such problems, including, insome embodiments, in an effort to facilitate cashless gaming whileensuring one or more of safe and responsible gaming, the timelyextension of credit, player honoring of obligations to the casino, andregulatory compliance, the Applicant has developed systems in whichfunds are automatically advanced either directly or from an intermediateaccount, such as a wager account, to a gaming device based, at least inpart, on a credit line of the player. In some embodiments, the creditline may be approved in advance, for example by the player submitting acredit application in person, on-line, via the mail, or the like. Thecredit line in some instances, may be approved while the player is in,for example, an operator property, such as a casino, based on one ormore of a written application submitted at that time, an oral request bythe player, an on-line application, an electronic request by the playerwhile using a gaming device, action by a casino employee even if notspecifically requested by the player, or the like.

In some embodiments, once credit has been extended to a player, any cashsubmitted by the player and any of the player's winnings may beselectively used to pay down the wager account, including in someembodiments at the direction of the casino based on, for example,certain automated rules, at the discretion of the player, or acombination thereof. In some applications, the player is encouraged toapply winnings or to insert cash to pay down the wager account.

In some embodiments, distribution of winnings by a gaming device to theplayer, for example in the form of cash or a cashout ticket, is disableduntil the wager account has been repaid. In certain embodiments, adistribution of at least a portion of the winnings is provided to theplayer when a wager account balance remains unpaid. In some embodiments,upon the occurrence of certain events, the passage of pre-determinedperiods of time, or both, a credit account is paid down, at least inpart, through authorized automated direct debiting of a player's fundingaccount, such as a bank account. This expedited paydown of creditaccounts can reduce the period of time where the casino might otherwisehave to maintain credit accounts with unpaid balances, reducingresulting cash flow shortages.

The collecting of relevant personal information at the time ofsubmitting a request for credit, combined with monitoring and trackingof credit advances and gaming activity, can provide improvedidentification of events triggering reporting requirements related tosuspicious activity and currency transaction amounts. In someembodiments, credentials, such as, for example, a driver's license canbe scanned and submitted as part of an electronic application process,allowing for the storage of the driver's license image and data whichmay be used in submission as part of an activity or transaction reportto a regulatory authority. In some implementations, the method and rulesfor the extension of credit, including, for example, the timing of andamount of extensions of credit, as well as the controls for rule-basedautomated pay down of wager and credit accounts can identify, prevent,or both, suspicious activities and reportable transactions.

In some systems, extending a credit line to a player and funding a wageraccount by advances against the credit line may be implemented, forexample, in a single gaming device such as a slot machine, a video pokermachine, or the like. Or a server may extend the wager account byelectronic communication across two or more devices so that the playercould use some of the credit line at one slot machine, some at anotherslot machine, a video poker machine, an electronic roulette machine, orthe like. All such gaming devices may be located at various pointswithin a casino or they may be located at more than one casino.

The server may include information respecting credit lines from manyplayers, and when any one of these players commences play at a gamingdevice that is in communication with the server, the player is asked toprovide some form of identification or password to enable access to thatplayer's credit line on that device. In some instances, these userinterfaces are familiar to players, such as touch screen interfacesprovides via a SMIB, which can reduce resistance or aversion totechnology adoption that might otherwise exist for certain demographics.

In some embodiments, tiered credit approval amount thresholds throttlethe timing of credit approval decisions, which in some applications canallow for an increased ability for the casino to include additionalactivity, including gaming activity and selective pay down activity, andfinancial information in credit approval decisions for the extension ofincreased credit amount requests. In some instances, these creditapproval tiers can be part of a responsible gaming service, controllingthe access to credit and thereby allowing the casino to avoid refusingto advance funds solely on the basis of the player's behavior. In someapplications, this can also provide benefit to the player as the easeand real-time nature of the system allows the player just-in-timeapproval and access to a line of credit without the player obtaining aninitial large line of credit that could negatively impact other aspectsof that player's financial state or credit worthiness.

In addition, in certain embodiments, a responsible gaming applicationservice can use these or other amount thresholds to provide one or moreof credit approval delay periods, credit access delay periods, or creditamount throttling. This can, in some embodiments, achieve the desiredgoal of controlling gaming behavior for responsible gaming purposewithout the undesirable consequence of making the player seek out a cashadvance machine or cashier to obtain additional funds when desired wherethere is no responsible gaming issue. In some instances, this can resultin an improved gaming experience, as well as improved velocity of cashentering the casino floor while simultaneously improving responsiblegaming management.

In some instance, funds are advanced directly from the credit line orcredit account to the gaming machine without first creating anintermediate account, such as, for example, a wager account or wallet,for tracking balances or amounts in a wager account or wallet. In someimplementations, the line of credit account is available for withdrawalfrom, or pay down through, an integrated banking service, such as anonline banking app. In some instances, automatic advances and paydownsoccur between a gaming machine interface, the credit account, and abanking institution.

Additional benefits and advantages can include the ability to obtaincredit request approvals in advance, during play, or both, thusimproving on floor funds management, reducing friction for player fundaccess, and increasing velocity of cash entering the casino floor. Thiselectronic-based method of credit transaction facilitation can, in someembodiments, reduce the cash management overhead costs as well,including one or more of reducing or eliminating the depositing offunds, reducing labor demands such as cage, vault, drop, and countteams, floor attendants, security personnel, and audit personnel,reducing the need for count machines and bank machines, reducing thecosts associated with paper management, and reducing interest to thecasino associated with large cash floats.

A further advantage of providing easily accessible managed wager creditis the reduction or elimination of players needing to carry cash. Bythis reduction or elimination in the cash carry, incidence of theft ofplayer funds can be reduced, resulting in one or more of improving thequality of the casino experience for patrons, decreasing costs to thecasino for liability coverage and security, increasing the number andfrequency of return player visits, and improving the reputation of thecasino with respect to potential customer perception, communityperception, or both. This can have a positive revenue impact on theoperator, reduce player losses due to theft, and foster a positivecommunity perception that can promote pro-casino local, state, andnational laws and regulations, as well as pro-casino zoning decisions.

In addition, the presence of easily obtained wager credit can reduce theburden on players by reducing or eliminating the need procure and managea substantial cash carry. Players can be free from having to considerwhere to obtain cash, and also having to consider the potential stakeneeded in advance for the relevant gaming period. Further, the presenceof easily obtained managed wager credit can reduce or eliminate theplayer burden of managing the cash carry while engaged in gaming,including the inconvenience of submitting cash to devices, tables, orsports book, retrieving of cash from devices, tables, or sports book,and the continued need to monitor cash not being played to avoid loss,such as by dropping bills or coins. The reduction or elimination of thisoverhead can improve the player experience, along with decrease playeranxiety that might otherwise due to, ate least in part, to the amount ofcash carried, the risk of losing a portion of that cash, or both.

The reduction to the cash-only nature of the casino gaming environmentcan have additional advantages and benefits applicable to communities.The reduction in the cash nature of the activity can reduce the burdenon community services, such as the demands placed on law enforcement,the courts, social and health care services, etc. With a reduced levelof due, at least in part, to the reduced presence of cash inside andoutside the casino, required police presence can be reduced, reducingthe overall cost of services, which can reduce both the burden ontaxpayers as well as improve the ability for such resources to focus onother more pressing criminal activity. Similarly, courts can experiencea decreased caseload as the number of arrests decline.

Source of funds tracking can be improved by, in certain instances,incorporating questions or source checks into the credit request andapproval process, thus reducing the operator's exposure for failing toreport source of funds violations. Further, such source of funds issuescan be addressed in advance of arrival at the casino, improving theplayer experience and reducing the cost to the operator of manuallymanaging such issues on the casino property.

In some embodiments, the operator enters into a loan warrantyingarrangement with a warrantor, which can be a commercial entity, thattakes a participation interest, such as an equity position, in anoperator receivable portfolio including one or more of receivablesrelated to advances made to players, receivables related to playerwagering losses, or both, or a partial or complete ownership interest inone or more credit accounts, credit account receivables, or both. Insome embodiments, such warrantying can provide to the operator one ormore of accelerated cashflow, guaranteed minimum advance returns, orboth. Additional benefits to the operator can include one or more of; a)managing of at least some player account status communications, such as,for example, notices, statements, demand notices of adverse action,collections, legal notices, and the like, b) real-time or near-real-time transactional online reporting, oversight, or both, c)treasury management and reporting, and d) credit account settlement andfinancial accounting support.

In some embodiments, the credit wager system and method of use with loanand warrantying provides for a tiered credit structure. This tieredstructure can one or more of; a) for given advance, mitigate the riskassociate with, at least in part, one or more of fraud, moneylaundering, or issues associated with bank secrecy laws, b) enablevalued and qualified players to increase their credit limit subject toappropriate and additional underwriting, taking into account, amongother factors, player history and overall value status to the casinooperator, and c) mitigate adverse or irresponsible player behavior thatmight otherwise jeopardize one or more of a player's personal financialwell-being, the relationship between the player and the casino operator,or both.

In some embodiments, the credit wager system and method of use with loanand warrantying can make available one or more of a variety of warrantorrevenue sources such as, for example, collecting credit application feesfrom the player or the operator, collecting warranty fees, whether suchwarranty fees are collected directly from the operator, as a percentageof advanced principal funds recovered, or indirectly through operatorreceivable purchase price discounts, collection of credit applicationscoring fees from the operator, and the like.

In some embodiments, the credit wager system and method of use with loanand warrantying can make available to the operator the ability for athird party to issue traditional consumer credit to a patron for thepurpose of wagering with an affiliated operator under an agreement thatpermits the third party to acquire or take an equity position in theplayer wagering losses from the operator at a predetermined discount,with associated service charges, or both.

Some credit wager system and method of use with loan and warrantying asdisclosed in this application can provide one or more of a variety oftechnical advantages including, but not limited to, reducing the memorystorage and bandwidth demands through targeted tracking of creditactivity during the credit approval phase and at near-realtime or inrealtime during the fund advancement phase during game play, improvingprivacy and security of personal information through reuse of collectedinformation with limited information proliferation, improving systemuser interface efficiencies through the streamlined applicationinterface and rule-based credit management features, reducingmulti-system processor load through the introduction of real-time ornear real-time, at-game, credit management, and the like.

Further, The applicant has developed a system that addresses variousinefficiencies existing in today's technologies and procedures relatingto the administration of credit lines associated with gaming activity byallowing patrons to control and direct the requesting of, drawing of,wagering of, and payment of credit lines and markers from a unifiedmobile interface using one or more of accessible cloud-based andon-premises services.

This approach can, in some embodiments, yield high efficiencies acrosssystems and processes, including one or more of:

-   Faster processing due to the reduction or elimination of manual    procedures, reduced system integrations, or both.-   Reduced processing and memory demand due, at least in part, to the    reduction or elimination of data duplication across systems.-   Reduced processing and memory demands through optimized identity and    credit verification procedures and reduced data retrieval and    replication using one or more of device verification methods, email    verification methods, linking with bank accounts, linking with    player's club accounts, linking with operator CRM systems, and the    like.-   Improved security due in part to reduced data transmission activity    resulting, at least in part, from the reduction of involvement of    multiple intermediary system stopping points.-   Reduced network bandwidth usage due to a reduction in system traffic    resulting from the elimination of some ad hoc processes such as    email verifications, file transfers, fax activity, system    integrations, scanning activity, and the like.-   Reduction in patron user error and frustration through a single,    simplified, unified graphical user interface, reducing or    eliminating paper submissions, phone verifications, and staff    engagement.

Additional benefits and advantages in some embodiments can include theability to obtain credit request approvals in advance, during play, orboth, thus improving on floor funds management, reducing friction forplayer fund access, and increasing velocity of cash entering the casinofloor. This electronic-based method of credit transaction facilitationcan reduce the cash management overhead costs as well, including one ormore of reducing or eliminating the depositing of funds, reducing labordemands such as cage, vault, drop, and count teams, floor attendants,security personnel, and audit personnel, reducing the need for countmachines and bank machines, reducing the costs associated with papermanagement, and reducing interest to the casino associated with largecash floats.

In some embodiments, the patron's increased visibility in and controlover credit lines can contribute to responsible gaming, allowing thepatron to easily monitor and control amount and timing of draws, as wellpaydowns. This can also provide benefit to the patron as the ease andreal-time nature of the mobile experience allows the player just-in-timeapproval and access to a line of credit without the player obtaining aninitial large line of credit that could negatively impact other aspectsof that player's financial state or credit worthiness.

The wagering account pooling system can support a process enrollingplayers and creating virtual player wagering accounts into which playerscan receive wagering advances, where the wagering advance is a virtualrepresentation of value, such as monetary value, that virtualrepresentation operable to be transmitted as an input to one or moreprocesses or gaming devices in the wagering account pooling system.

In some embodiments, the virtual player wagering account allows playersto engage in wagering activity with, for example, participatingphysical, online and mobile casinos, race and sports book operatorsusing wagering advances, or player's winnings or credits on deposit inthe virtual player wagering accounts resulting from, for example priorwagers, and the like.

In some embodiments, a wagering advance to a virtual player wageringaccounts is provided following a financial capability assessment scorewhich may assess financial capability attributes, such as, for example,one or more of: a) traditional credit bureau scoring; b) alternatefinancial information; c) bank history; d) source of household income;e) combined household debt; f) prior player wagering behavior with theoperator; g) derogatory information within specialized gaming industryplayer bureaus, and the like.

In some implementations, an individual player wager advance limit is setbased on, for example, a matrix which assesses, for example, amongstother factors, a player's financial capability assessment score,operator risk tolerance, third-party financial services entity risktolerance, local regulatory guidance, and player's established historywith the operator.

In some instances, a player may draw a wagering advance, generating acrediting event to their virtual player wagering accounts. In someinstances, at least a portion of the wagering advance amount shall bedue for repayment by player on a date certain following the gaming dayof said wagering advance, such as, for example, a day between fifteen tothirty days, but subject to substantial variation on, for example, aregion by region basis, an operator to operator basis, and the like.

In some embodiments, a player not otherwise restricted may draw awagering advance up to their remaining advance limit, at any time up totheir designated advance limit to post a virtual credit to their virtualplayer wagering account and make wagers with participating operators. Insome instances, additional advance sources are available in excess ofthe advance limit that can be used to provide a wagering advance. As theplayer elects to secure a wagering advance to their virtual playerwagering account, their associated advance limit is decrementedaccordingly. In some implementations, when a Player has exhausted theiradvance limit, when an advance becomes due, or both, the P virtualplayer wagering account is frozen and the player is not able to makefurther wagers until the past due advance sum has been repaid to theoperator account.

In some embodiments, the wagering account pooling system may allocatefees to the player, the operator, or both for one or more events, suchas, for example, the enrolment of a player, provision to operator of theplayer's financial capability assessment score, provision to player of awagering advance and/or the management of the advance issue for aLicensed Operator, repayment by player or collection from the player ofthe wagering advance and associated fees, the wagering with an operatorfrom a virtual player wagering account, and the management for theoperator of the advance and wagering ecosystem.

In some instances, the advance to the player is provided on anon-interest bearing basis and may be subject to one or more governmentregulations or may be offered to a player by the operator or third-partyfinancial service provider, with an applicable interest factor orinstallment repayment fee.

In some instances, the virtual player wagering account may be managed byor on behalf of the participating operator in collaboration with, orindependently by, an affiliated partner which in certain jurisdictions,which would be an appropriately licensed and/or regulated financialinstitution or bank.

In some implementations, the individual virtual player wagering accountsare treated as part of a consolidated or pooled account where allvirtual player wagering accounts create a joint asset base and alldeposits of the collective virtual player wagering account holders canbe, for example, guaranteed by one or more of a financial institution,the wager account pooling system provider, or other third party. In someembodiments, the pooled account acts as a consolidated account hostingthe individual virtual player wagering account balances for all or aportion of the enrolled players. In some instances, when players areenrolled and actively wagering, player wagers are treated as anaggregate daily wager from the pooled account, and wins and losses aresettled in aggregate at the completion of a game period with theoperator on behalf of the aggregate wagering of all the players in thepooled account, while individual player virtual player wagering accountsare settled independently.

In some implementations, player virtual player wagering accountsmaintain a virtual balance until a player elects to cash-out anddisburse a virtual player wagering account balance to, for example, theplayer's designated bank account, upon which event, the wagering accountpooling system initiates an allocation of funds disbursement activityfirstly to repay any outstanding wagering advances and their associatedfees, followed by disbursement to the player's designated account, suchas, for example the player's personal bank account. Virtual playerwagering accounts may remain active following a disbursement of all orsubstantially all of the available funds until, for example, closed by aplayer's specific request, the direction of a participating financialinstitution, a directive of a regulatory authority of competentjurisdiction, a directive of the participating operator, or inaccordance with wagering account pooling program participation rules.

The obligations of the pooled account, such as, for example, funding thedaily wagering obligations of all enrolled players may be borne by theoperator, a participating financial institution, a participating thirdparty financial partner, and the like.

In some embodiments, the wagering account pooling system provider willoperate a program where players may receive interest ornoninterest-bearing wagering advances for specified periods while theparticipating operators will be guaranteed a daily settlement based onthe player's losses incurred by the total players participating in eachgame day wagering via the pooled account (“Aggregate Game Day Hold”). Insome instances, operators my receive 100% of the Aggregate Game Day Holdor a discounted value based on agreement between the operator and one ormore of the wagering account pooling system provider, participatingaffiliate, or warrantor.

It is to be understood that this Brief Summary section recites somenovel aspects of the present disclosure, but there are other novel andadvantageous aspects disclosed in this specification. They will becomeapparent as this specification proceeds. In this regard, the scope ofthe invention is to be determined by the claims as issued and not bywhether a claim addresses any or all issues noted in the Certain Aspectssection or includes a feature included or not included in this BriefSummary section.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of the embodimentsmay be realized by reference to the following drawings. In the appendedfigures, similar components or features may have the same referencelabel. Further, various components of the same type may be distinguishedby following the reference label by a dash and a second label thatdistinguishes among the similar components. If only the first referencelabel is used in the specification, the description is applicable to anyone of the similar components having the same first reference labelirrespective of the second reference label.

The applicants' preferred and other embodiments are disclosed in theaccompanying drawings in which:

FIG. 1 is a block diagram of participant and system relationships forthe credit wagering system and method of use with loan and warrantying;

FIG. 2A is a block diagram of front-end gaming components of a creditwagering system with loan and warrantying supporting the relationshipsand activities of FIG. 1;

FIG. 2B is a block diagram of the systems integration framework of acredit wagering system with loan and warrantying supporting the externalsystems relationships and activities of FIG. 1;

FIG. 3 is a block diagram of the cloud and on-premise back-endcomponents of the credit wagering system with loan and warrantying ofFIG. 2B;

FIG. 4 is a block diagram of one example of a back-end system componentsarchitecture that can underly the deployment of the cloud and on-premisecomponents of FIG. 3;

FIG. 5 is a block diagram of the services layers of the credit wageringsystem with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 6 is a block diagram of the services and engines of the serviceslayers of FIG. 5 performing the various operations of the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 7A is a flowchart of a method for during-play processing of creditapplications and approvals by the credit application services layer ofFIG. 5 in the credit wagering system with loan and warrantying of FIG.2B and FIG. 3;

FIG. 7B is a flowchart of a method for allocating fees among theparticipants of FIG. 1;

FIG. 7C is a flowchart of a method for using an external service for thecredit application scoring of FIG. 7A by the credit application serviceslayer of FIG. 5 in the credit wagering system with loan and warrantyingof FIG. 2B and FIG. 3;

FIG. 8 is a flowchart of a method for in-advance processing of creditapplications and approvals by the credit application services layer ofFIG. 5 in the credit wagering system with loan and warrantying of FIG.2B and FIG. 3;

FIG. 9 is a flowchart of a method for an in-advance approval of creditapplications by the credit application services layer of FIG. 5 in thecredit wagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 10 is a flowchart of a method of responsible gaming approvals bythe responsible gaming services layer of FIG. 5 in the credit wageringsystem with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 11 is a flowchart of a method of tiered approval credit thresholdsin the credit wagering system with loan and warrantying of FIG. 2B andFIG. 3;

FIG. 12 is a flowchart of a method of intermittent credit accountreconciliation by the account services layer of FIG. 5 in the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 13 is a flowchart of a method of monitoring for credit transactionreport triggering events by the compliance services layer of FIG. 5 inthe credit wagering system with loan and warrantying of FIG. 2B and FIG.3;

FIG. 14 is a flowchart of a method of monitoring for structuretransactions by the compliance services layer of FIG. 5 in the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 15 is a flowchart of a method of monitoring for minimal gamingconditions by the compliance services layer of FIG. 5 in the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 16 is a block diagram of the win/loss aggregate game periodsettlement pool method for distributing revenue share based on wagerloss receivable participation interests;

FIG. 17 is a flowchart of a method of managing and settling virtualplayer wager accounts and revenue sharing using a win/loss aggregategame period settlement pool in the credit wagering system with loan andwarrantying of FIG. 2B and FIG. 3;

FIG. 18 is another flowchart extending the method of FIG. 16 formanaging and settling virtual player wager accounts and revenue sharingusing a win/loss aggregate game period settlement pool in the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 19A and FIG. 19B are flowchart diagrams of an example of managingand settling virtual player wager accounts using a win/loss aggregategame period settlement pool of FIG. 17 and FIG. 18;

FIG. 20 is a screen capture of the create new account view of the mobileapplication of FIG. 1;

FIG. 21 is a flowchart of create new account method by theauthentication and other services of FIG. 3 in the credit wageringsystem with loan and warrantying of FIG. 2B and FIG. 3 that interfaceswith the create new account view of FIG. 20;

FIG. 22 is a screen capture of the player information view of the mobileapplication of FIG. 1;

FIG. 23 is a flowchart of player information method by theauthentication and other services of FIG. 3 in the credit wageringsystem with loan and warrantying of FIG. 2B and FIG. 3 that interfaceswith the player information view of FIG. 22;

FIG. 24 is a screen capture of the create new account phone verificationview of the mobile application of FIG. 1;

FIG. 25 is a flowchart of create new account phone verification methodby the authentication and other services of FIG. 3 in the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3 thatinterfaces with the create new account phone verification view of FIG.24;

FIG. 26 is a screen capture of the phone verification failednotification view of the mobile application of FIG. 1;

FIG. 27 is a flowchart of phone verification failed notification methodby the authentication and other services of FIG. 3 in the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3 thatinterfaces with the phone verification failed notification view of FIG.26;

FIG. 28 is a screen capture of the link bank account view of the mobileapplication of FIG. 1;

FIG. 29 is a flowchart of link bank account method by the authenticationand other services of FIG. 3 in the credit wagering system with loan andwarrantying of FIG. 2B and FIG. 3 that interfaces with the link bankaccount view of FIG. 28;

FIG. 30 is a screen capture of email verification failed notificationview of the mobile application of FIG. 1;

FIG. 31 is a screen capture of the get location view of the mobileapplication of FIG. 1;

FIG. 32 is a flowchart of get location method by the authentication andother services of FIG. 3 in the credit wagering system with loan andwarrantying of FIG. 2B and FIG. 3 that interfaces with the get locationview of FIG. 31;

FIG. 33 is a screen capture of the credit check with social securitynumber view of the mobile application of FIG. 1;

FIG. 34 is a screen capture of the offer advance line where unable toextend credit view of the mobile application of FIG. 1;

FIG. 35 is a flowchart of credit check method by the services of FIG. 3in the credit wagering system with loan and warrantying of FIG. 2B andFIG. 3 that interfaces with the credit check view of FIG. 33 and theoffer advance line where unable to extend credit view if FIG. 34;

FIG. 36 is a screen capture of the offer advance line able to extendcredit view of the mobile application of FIG. 1;

FIG. 37 is a flowchart of the offer advance line able to extend creditmethod by the services of FIG. 3 in the credit wagering system with loanand warrantying of FIG. 2B and FIG. 3 that interfaces with the offeradvance line able to extend credit view of FIG. 36;

FIG. 38 is a screen capture of the enrollment confirmation view of themobile application of FIG. 1;

FIG. 39 is a screen capture of the login view of the mobile applicationof FIG. 1;

FIG. 40 is a screen capture of the reset password view of the mobileapplication of FIG. 1;

FIG. 41 is a screen capture of the user mobile dashboard view of themobile application of FIG. 1;

FIG. 42 is a screen capture of the user mobile recent activity view ofthe mobile application of FIG. 1;

FIG. 43 is a screen capture of the user mobile to do list view of themobile application of FIG. 1;

FIG. 44 is a screen capture of the manage markers view of the mobileapplication of FIG. 1;

FIG. 45 is a screen capture of the outstanding markers view of themobile application of FIG. 1;

FIG. 46 is a screen capture of the make a payment view of the mobileapplication of FIG. 1;

FIG. 47 is a screen capture of the verify payment view of the mobileapplication of FIG. 1;

FIG. 48 is a screen capture of the successful payment view of the mobileapplication of FIG. 1;

FIG. 49 is a screen capture of the statement view of the mobileapplication of FIG. 1;

FIG. 50 is a screen capture of the transactions view of the mobileapplication of FIG. 1;

FIG. 51 is a screen capture of the notifications view of the mobileapplication of FIG. 1;

FIG. 52 is a screen capture of the settings view of the mobileapplication of FIG. 1;

FIG. 53 is a screen capture of the personal information view of themobile application of FIG. 1;

FIG. 54 is a screen capture of the address view of the mobileapplication of FIG. 1;

FIG. 55 is a screen capture of the phone number view of the mobileapplication of FIG. 1;

FIG. 56 is a screen capture of the email address view of the mobileapplication of FIG. 1;

FIG. 57 is a screen capture of the manage bank account view of themobile application of FIG. 1;

FIG. 58 is a screen capture of the unlink bank account view of themobile application of FIG. 1;

FIG. 59 is a screen capture of the manage notifications view of themobile application of FIG. 1;

FIG. 60 is a screen capture of the manage sms text notifications view ofthe mobile application of FIG. 1;

FIG. 61 is a screen capture of the legal view of the mobile applicationof FIG. 1;

FIG. 62 is a screen capture of the privacy policy view of the mobileapplication of FIG. 1;

FIG. 63 is a screen capture of the terms and conditions view of themobile application of FIG. 1;

FIG. 64 is a screen capture of the legal notices view of the mobileapplication of FIG. 1;

FIG. 65 is a screen capture of the problem gambling view of the mobileapplication of FIG. 1;

FIG. 66 is a wireframe of an account access view of the touch display ofFIG. 2B;

FIG. 67 is a wireframe of an account authorization view forauthenticating credit account access pool in the credit wagering systemwith loan and warrantying of FIG. 2B and FIG. 3;

FIG. 68 is a wireframe of the credit account amount selection and useview pool in the credit wagering system with loan and warrantying ofFIG. 2B and FIG. 3;

FIG. 69 is a wireframe of the credit line request view pool in thecredit wagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 70 is a wireframe of the credit request authorization, fee, andterms acceptance view pool in the credit wagering system with loan andwarrantying of FIG. 2B and FIG. 3;

FIG. 71 is a screen capture mobile app credit request view in the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 72 is a screen capture mobile app credit approval view in thecredit wagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 73 is a screen capture mobile app credit account view in the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 74 is a screen capture mobile app credit advance view in the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 75 is a screen capture mobile app fee acceptance view in the creditwagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 76 is another screen capture mobile app fee acceptance view in thecredit wagering system with loan and warrantying of FIG. 2B and FIG. 3;

FIG. 77 is a screen capture mobile app funds transfer confirmation viewin the credit wagering system with loan and warrantying of FIG. 2B andFIG. 3;

FIG. 78 is a wireframe authentication view of the operator dashboard ofFIG. 3;

FIG. 79 is a flowchart of an authentication method by the authenticationservice of FIG. 3 in the credit wagering system with loan andwarrantying of FIG. 2B and FIG. 3 that interfaces with theauthentication view of FIG. 28;

FIG. 80 is a wireframe operator listing view of the operator dashboardof FIG. 3;

FIG. 81 is a flowchart of an operator listing method by the accountservices layer of FIG. 5 in the credit wagering system with loan andwarrantying of FIG. 2B and FIG. 3 that interfaces with the operatorlisting view of FIG. 30;

FIG. 82 is a wireframe operator detail view of the operator dashboard ofFIG. 3;

FIG. 83 is a flowchart of an operator detail method by the accountservices layer of FIG. 5 in the credit wagering system with loan andwarrantying of FIG. 2B and FIG. 3 that interfaces with the operatordetail view of FIG. 32;

FIG. 84 is a wireframe add new user view of the operator dashboard ofFIG. 3;

FIG. 85 is a flowchart of an add new user method by the account serviceslayer of FIG. 5 in the credit wagering system with loan and warrantyingof FIG. 2B and FIG. 3 that interfaces with the add new user view of FIG.34;

FIG. 86 is a wireframe user detail view of the operator dashboard ofFIG. 3;

FIG. 87 is a flowchart of a user detail method by the account serviceslayer of FIG. 5 in the credit wagering system with loan and warrantyingof FIG. 2B and FIG. 3 that interfaces with the user detail view of FIG.36;

FIG. 88 is a wireframe patron listing view of the operator dashboard ofFIG. 3;

FIG. 89 is a flowchart of a patron listing method by the accountservices layer of FIG. 5 in the credit wagering system with loan andwarrantying of FIG. 2B and FIG. 3 that interfaces with the patronlisting view of FIG. 38;

FIG. 90 is a wireframe patron detail view of the operator dashboard ofFIG. 3;

FIG. 91 is a flowchart of a patron detail method by the account serviceslayer of FIG. 5 in the credit wagering system with loan and warrantyingof FIG. 2B and FIG. 3 that interfaces with the patron detail view ofFIG. 40;

FIG. 92 is a screen capture online banking view with an integrated lineof credit managed by the credit wagering system with loan andwarrantying of FIG. 2B and FIG. 3;

FIG. 93 is a block diagram of a computer system suitable forimplementing the present systems and methods of FIG. 1;

FIG. 94 is a table of an example tier one initial score-to-creditapproval schedule for use in the approval process of FIG. 7C;

FIG. 95 is a table of an example tier two score-to-credit approvalschedule for use in the approval process of FIG. 7C;

FIG. 96 is a table of an example tier three score-to-credit approvalschedule for use in the approval process of FIG. 7C; and

FIG. 97 is a table of an example tier four score-to-credit approvalschedule for use in the approval process of FIG. 7C.

DETAILED DESCRIPTION OF THE PREFERRED AND OTHER EMBODIMENTS

Broadly, this application is directed to a credit wager system andmethod of use, in some embodiments, with one or more among loan andwarrantying. factoring, or aggregation of at least portions of accounts,and aggregate processing. The methods disclosed in the presentapplication can be implemented in many different ways, including throughsoftware, hardware, firmware, remote processing, or the like, or acombination thereof. The method is directed to use with a gaming device,but the term “gaming device” includes all machines involved in theprocess of conducting and funding gaming activity and should not belimited to slot machines and video poker machines. “Gaming device” mayinclude any device used in gaming that receives, dispenses, or transfersa medium of exchange, such as coins, cash, vouchers, tickets, gamingchips, or other fungible value media, or electronic representationsthereof, including cryptocurrencies. This can include chip and tickethandling machines that convert gaming chips, tickets, game credits, orelectronic representations thereof, into currency or cryptocurrency.Moreover, this application specifically contemplates use of the presentmethod and system with gaming tables, and all wager gaming, includingspecifically mobile wager gaming, and table games, sports book, andracing applications, such as horse and dog racing for example, orportions of any such activity such as by providing an automated wagergaming money or value advancing and monitoring application for use inconjunction with wager gaming.

Also, it is contemplated that the present method can be implemented atone or more gaming devices. That is, the method can be implemented at asingle gaming device, a plurality of gaming devices operatingseparately, a plurality of networked gaming devices, a plurality ofgaming devices networked with a server controller, a gaming device incombination with a mobile device, or any combination or variationthereof. For purposes of this application, the term “casino” includesconventional casinos as well as all other providers of any wager gamingand wager gaming system, including online gaming, race book, sportsbook, and remote device gaming.

In some embodiments a credit wager system with loan and warrantyingincludes the collecting of a loan origination fee, loan transaction fee,or the like that the player pays as part of an initial application for acredit line. The amount of this fee may be different depending onvarious conditions, such as, for example, whether the player submits anapplication on-line or on paper, whether the application is made aheadof time or at the casino, whether the application can be processedelectronically or must be handled by casino employees, whether credit isbeing issued by the operator, warrantor, or a third-party financialprovider. In some situations, such as an electronic request through agaming device while the player is actually using the gaming device, thefee may be lower or higher than other loan fees or may be waivedentirely.

In some embodiments, the casino enters into a loan warrantyingarrangement with a commercial entity (the warrantor) that takes aproprietary interest, such as a partial or complete ownership interest,in one or more credit accounts, credit account receivables, or both. Insome instances, the warrantor acquires an equity interest as apercentage of advances made to players during a certain period, such asa 24-hour period. This can be accomplished by, for example, the transferof funds to the casino operator equal to a percentage, such as adiscount in some embodiments, of one or more new advance originationsinitiated in the defined period. In return, the warrantor can receive apercentage of the first-recovered repayments of advanced amounts up tothe previously funded amounts from that defined period (the warrantyguarantee amount), plus an additional percentage amount (the warrantyservice amount). In some embodiments, the warranty service fee isreceived by the warrantor on scheduled basis over a certain collectionperiod.

In some instances, the warrantor can participate in one or more ofsolely or jointly reviewing and approving the casino's method forestablishing credit lines before issuing credit to a player. In someinstances, the warrantor requires that it participate in the creditapproval process, for example, by doing the approval itself, throughanother entity, or jointly. In some cases, approval is performed, atleast in part, electronically or in some other manner. In someembodiments, the warrantor can use one or more of a variety of known andobtained credit-related attributes, such as, for example, attributesobtained from hard credit inquiries, soft credit inquiries, employmentverification services, funding account verification services, fungibleasset verification services, fund transfer monitoring services, and thelike, to determine credit-worthiness and whether to extend some amountof credit to a player. When a player uses a certain amount of credit andloses the money in wagering, the warrantor can hold an equity positionin the receivable for that amount, or in the alternative, take partialor complete ownership in the receivable. Reconciliation between thecasino and the warrantor can take place from time to time, for examplehourly, daily weekly or monthly, and can involve one or more of thefollowing:

-   1. Detail and total of all credit advanced to one or more players    during the reconciliation period.-   2. Detail and total of all credit line paydown events by one or more    players, such as through automated paydowns at the time of machine    cash out, or discretionary paydowns through submissions of payment    at a game machine, cash machine, funds transfer enabled app, or    cage.-   3. The difference between these amounts can equal the amount    advanced to the casino (for example via ACH or some other electronic    method) or, in the case of collections exceeding advances, returned    to the warrantor.

As an example that may take place in certain embodiments, assume thereare two players, Player #1 and Player #2, whose accounts are part of thewarrantying account set. Further on a given day Player #1 uses $1,000 ofhis/her credit line and loses all of it at the machine. Meanwhile,Player #2 uses $500 of his/her credit line, hits a jackpot for $750, andpresses “cash out” thereby automatically repaying the $500 draw onhis/her credit line and receiving the balance of $250 in cash. Atreconciliation, the warrantor would reimburse the casino for $1,000 orapplicable part thereof as agreed under a warranty Advance receivableparticipation or sale/purchase agreement with Casino because that is theamount advanced to the casino ($1,000 for Player 1 plus $500 for Player2) net of the $500 repaid by Player #2. If Player #1 returns the nextday, draws another $500 on his/her line of credit, hits a $2,000 jackpotand presses “cash out”, the $1,500 drawn on his/her credit line ($1,000on the first day plus $500 on the next day) is automatically repaid andthe player receives the balance of $500 in cash. At reconciliation, thecasino would reimburse the warrantor for $1,000 on the account of Player#1 because that is the net amount received back from that player by thecasino ($1,000 on the first day plus $500 on the second day minus $500repaid by the player on the second day).

In some embodiments, if the funds for the credit line are provided byanother party such as a warrantor either in advance of the granting ofthe credit or after the credit has been extended, the transaction isreported to that party. This report can include the amount of the creditand identity of the player or players, and any other informationdesired. In some instances, the player's or players' obligations may bepurchased from the casino at a discount. In some embodiments, fees arecharged to one or more player at one or more stages of the process.

In some embodiments, a loan transaction fee may be charged each time theplayer requests an advance, such as, for example, to a wager account,against the player's credit line. This can be done electronically, forexample by a message displayed on a screen of a gaming device to theeffect that a request for a credit advance of, for example, $100 willresult in a debit of $103 from the player's credit line even though only$100 will be made available at the gaming device for the player to usein wagering. The fee may be a fixed amount for each request, apercentage of the credit line, a percentage of the amount beingadvanced, or the like.

Referring now to FIG. 1, in some embodiments, various participants andsystems can interact as part of the applying for, extending,transferring, and managing credit in connection with the method andoperation of the credit wager system with loan and warrantying,particularly where loan warrantying is involved. In some instances, acasino operator 105 operates one or more gaming devices operable toreceive wagerable funds from an intermediate account, such as, forexample, a wager account 115. A player 120 can withdraw funds, accessfunds, or both in the wager account 115 through one or more interfaces,such as, for example, the gaming device 110 primary interface, through asecondary gaming device interface, through an end user credit managementapp 125 that runs on, for example, a mobile device or a casino device,or the like.

In some implementations, the wager account 115 can be funded, at leastin part, from one or more credit accounts 130, can add to or pay downthe balance in the one or more associated credit accounts 130, or both.This adding or paying down of the credit account 130 can be effected byplayer 120 at player's discretion via interfacing with the end usercredit management app 125, the gaming device 110 interface, or both. Insome instances, the adding or paying down of the credit account 130occurs, at least in part, automatically upon the occurrence of certainevents, such as, for example, an attempted cash out event. In someembodiments, the one or more credit accounts 130 are associated with abank account 135 which can be accessed via a banking app 140 displayingcredit account information 9200 (e.g., see FIG. 92). In some instances,one or more credit accounts 130 are directly accessible via the bankingapp 140.

In some embodiments, one or more warrantors 145 have a proprietaryinterest, such as a partial or complete ownership interest in accountsreceivables associated with one or more credit accounts, and can assistwith, take responsibility for, or both, collection of such accountsreceivables. In some instances, the warrantor 145 participates indecision involving the extension of credit, collection of accountsreceivables, or both. One or more secondary market credit buyers 150 maypurchase, or otherwise invest in, individual credit accounts 130 orpackages of credit accounts 155 or their associated accountsreceivables.

Referring now to FIG. 2A, in some embodiments, a networked gaming system200 includes and is operable to support a wager credit managementservice 205. In some embodiments, the wager credit management service205 communicates with a host server (controller) 219 over network 218,one or more external services 216, or both. In certain instances, thisnetwork can be a virtual private network. The controller 219 can beoperatively coupled to a local database and may optionally be a serveron the casino premises. The controller 219 can be operatively coupled toone or more gaming devices 220. Some game devices 220 can include acurrency acceptor 225, a card reader 230, and/or a hopper mechanism 235.Some game devices can be connected to an external system interface 240,an external touch display 245, or both.

Gaming devices 220 can be interfaced to the controller 219 by variousmethods. One exemplary method (not shown) involves interfacing gamingdevices 250, 255, 260 to a fiber tap board. The fiber tap boards can bedaisy-chained together to connect multiple gaming devices 250, 255, 260to a single controller 219. To distinguish one gaming machine fromanother when using a daisy-chained configuration, gaming machines 250,255, 260 can support an automated and/or attendant configurable systemaddress range assignment.

In another embodiment, a smart interface board (SMIB) 265, 270 connectsgaming devices 250, 255 to a controller 219 via, for example, aserial-to-tcp/ip converter 275 connected to the controller 219 via, forexample, USB. One example of a commercially available serial-to-tcp/ipis the Lantronix UDS1100 External Device Server. The SMIB 265, 270 canpoll the gaming device 250, 255 to which it is connected and pass theinformation for that gaming device 250, 255 to the controller 219. Insome instances, the SMIB 270 is installed in the gaming device 255 andconnected to a master communication board 280. In other instances, theSMIB 265 can be part of an external interface device 240. In certaininstances, the gaming device 260 is designed to interface directly withthe controller 219 without a SMIB. In some instances, mobile gamingdevices 285 and wireless gaming devices 290 communicate with thecontroller 219 over a wireless LAN 295 over protocols such as TCP/IPand/or UDP. In certain instances, gaming devices 220 include one or morevirtual gaming devices, such as, for example, devices that support andfacilitate one or more of, participation, observation, and wagering ingaming activities such as online gaming, sports book, race book, and thelike.

In certain instances, the controller 219 requests data by sendinggeneral polls and long polls to the gaming devices 220. General pollsare sent to the gaming devices 220 to obtain event information. In someembodiments, gaming devices respond to general polls with a single byteexception code indicating that an event has occurred. For example, whenthe controller 219 desires accounting information, such as the gamingdevice's managed credit meter total, it issues a long poll requestingthe specific data. When responding to a host long poll, the gamingdevice 110 message can include its address, host command, requesteddata, and a two-byte cyclical redundancy check (CRC).

In some applications, the controller 219 calculates a CRC for one ormore types of long polls. The CRC is calculated over the entire packet,including, for example, the address and command byte, with an initialseed value of zero. The gaming device 220 calculates the CRC in the samemanner for one or more multi-byte long poll responses.

Cases may arise where the wager credit management service 205 is offlineor otherwise unavailable to the controller 219. When the connectionbetween the wager credit management service 205 and the controller 219are interrupted, there is the potential to lose credit managementauthorization data, transactional data, or both. In some applications,messages are placed on a transmit queue and subsequently dequeued afterreceipt by the wager credit management service 205.

In some embodiments, the controller 219 can configure a gaming devicefor real-time event reporting. Gaming devices 220 can respond with anexception message including, for example, its address, an event responseidentifier, an exception code, any additional data, and a two-byte CRC.When in this mode, gaming devices 220 can respond to long polls withevent responses.

Referring now to FIG. 2B, in some embodiments, the credit wager systemwith loan and warrantying 205 integrates with a one or more externalsystems 216 through an external systems connector service 215, creatinga multi-system integration configuration 217. In some embodiments,external systems data, functions, or both are engaged via externalsystems API interfaces in communication with the external systemsconnector service 215, the external systems including one or more of; a)one or more verification systems 206 for providing verification of oneor more of player identification data, player credentials, employmentinformation, bank account information, and the like (e.g., Dwolla™,Yodlee™, Plaid™, etc.) b) a player's club system 207 for one or more ofsharing player, game play, player account, and reward related data andfunctions, c) a funding system, such as a banking system 208 for one ormore of making automated direct deposits or automated direct debit, d) afraud verification system 209 for detecting fraudulent activity, data,or behavior, e) casino management system 210 for engagement with casinomanagement functions and data, f) payment management solution 211, g)credit screening system 212 for the execution of credit screeningincluding checking derogatories, performing soft checks, hard checks, orboth, h) one or more credit scoring systems 213 for obtaining creditrelated scoring output to, at least in part, determine a degree ofcredit worthiness, and i) one or more compliance reporting systems 214for automated filing of compliance and regulatory reports.

Referring now to FIG. 3, in some instances, the back-end architectureincludes one or more of a set of cloud services 301, a set of on-premiseservices 302, and a set of external services 303, with access to one ormore services provided to one or more user interfaces 304. in someembodiments, one or more user interfaces 304 access one more cloud oron-premise services either directly or indirectly. These user interfacescan include, for example, at-property interfaces 305, mobile interfaces310, web interfaces 315, and an operator dashboard 320.

In some implementation, a dashboard service allows one or more ofproperty operators, staff, system operators, warrantors, and the like tologin and view a given operator's program status and activity. Theend-user dashboard interface 320 communicates with the dashboardservices via an operator dashboard API 335, the end user interface 320displaying information about a given operators program and patrons,generating report data through engagement with a reporting database 340,or both. In some instances, some or all communication with the operatordashboard API is performed over HTTPS.

In some embodiments, one or more user interfaces 304 communicate withone or more cloud services 303, on-premise services 302, or both via anAPI gateway 320. In some instances, interfacing with an on-premiseservice is indirect, first engaging one or more cloud services 301 viathe API gateway 320, such as the authentication service 345, supportedby an authentication/user database 350. In certain implementations, userinterface interactions and back-end interactions with external servicesand their respective external service API's 355 include engagementthrough the API gateway 320.

In certain implementations, one or more one or more credit wager systemand method of use with loan and warrantying services are operatedon-premise at a property location, such as at a casino or its associateddata center. This can include an on-premise server instances 360 incommunication with one or more of a casino management system 365, aunified wallet system 370, an accounting system ledger 375, and otherservices, any of which may be supported by one or more on-premisedatabases 380.

Referring now to FIG. 4, in some embodiments, at least some of thecomponents of the remote wagering credit administration systeminfrastructure are designed to operate in a cloud environment and canbe, for example, deployed as a container cluster, such as a Kubernetescluster, managed, at least in part, through a container administrationinterface 430 and container registry 435 in communication with acontainer orchestration engine 425. Load balancing of traffic, such astraffic related to at-property interfaces 305 and game managementinterfaces 405, can occur through an independent load balancer 415, atthe Ingress controller 420, or both. Ingress 420 can expose HTTP andHTTPS routes from outside the cluster to services within the cluster.Traffic routing can be controlled by rules defined on the Ingressresource. The ingress may be configured to give one or more servicesexternally-reachable URLs, load balance traffic, terminate SSL/TLS, andoffer name based virtual hosting. This can allow for unified managementof application services as well as one or more of logging, healthchecks, encrypted communications between services, as well asintegration with additional security services for one or more ofcertificate issuance, load balancing, application isolation and otherfeatures.

Infrastructure components and hardening can include one or more of:

-   a) OpenVPN tunneled connections to one or more components, including    on-premises components. Hardening of OpenVPN connections can include    one or more of:    -   a. Keys, such as, for example, 2048-bit RSA keys;    -   b. Unique keys for each system and link;    -   c. TLS-Auth key utilization for prevention against scanning, DOS        and brute-force attacks; and    -   d. Managed CRL for disused key;-   b) Sealed Kubernetes hosts (i.e., once infrastructure hosts are    deployed, no host system access is available;-   c) Write-only security logging—Application, firewall, load balancer,    database and system logs can be published to, for example, a SIEM    logging service. And-   d) Minimum-knowledge application isolation, where one or more    services that communicates with on-premises devices can be isolated    within its own container with its keys, such as customer-specific    security keys. This can provide a logical isolation between    customers.

In some embodiments, the warp server 460 web service allows patrons toperform certain tasks and operations, such as, for example, logging inand viewing their account history and status from the web or other userinterface, rendering a series of webpages or views depending on whataddress is input into the web browser address bar or selectioninterface. Communication can be facilitated via the API gateway 320using HTTPS/TLS encryption over XHR requests requesting informationabout the given patrons account and status over this protocol. One ormore additional warp web servers 455 can service requests involvingthird-party systems API's 410, unified wallet communications 370, orboth. One or more databases 465 can provide support to the one or morewarp servers 455, 460 and associated services. On-premise components canbe further managed through various administrative interfaces andcomponents, such as, for example, a services administration interface440, an administrative client interface 445, and a command lineinterface 450.

In some embodiments, the warp server instance 460 allows patrons toperform one-off actions from communications flows such as, for example,password reset, email verification, email unsubscribe actions, renderinga series of webpages depending on what address is input into the webbrowser address bar or selection interface. Client web browserscommunicate with it using, for example HTTPS/TLS encryption, and thewarp server instance communicates in the background with the appropriateAPI's.

The API gateway 320 can include interfaces supporting functionality fora patron of a given operator's program to be one or more of onboarded orscored, and to maintain their account on an ongoing basis. In someinstances, the API and associated services communicate with one or moredatabases in order to maintain state and store at least some informationneeded to fulfill player program requirements. API functionality caninclude, but is not limited to:

-   a) Onboarding/Underwriting—the business logic used to perform    underwriting by communicating with, for example, Equifax and other    3rd party partners to validate the players identity, offer the    correct advance line based on a matrix of possible advance lines,    and the like;-   b) Payments—maintain connectivity with, for example, an ACH    provider, in order to process regularly scheduled payments against    the patrons outstanding balances, as well as on-demand payments;-   c) Ledger Communications—maintain communication with the accounting    system with ledger 375 (e.g., see FIG. 3) in order to update it of    posted or pending payments as well as reversals. Additionally, in    some instances, the API provides an interface for retrieving    information regarding the players latest transactions from the    ledger in order to display that to the patron;-   d) Geofencing—validate whether or not a given patron is located    within a pre-specified geographic area or whitelisted IP address in    order to perform operations identified as needing to be performed at    a specific geographic location;-   e) On-Premise Communications—In some implementations, the on-premise    components retrieve customer information from the property casino    management system in order to verify information in the onboarding    process as well as send the initial line information to the    on-premise services so that patrons can begin to draw against an    approved and accepted credit line.-   f) Authentication—maintain communication with the authentication    service in order to validate that a given patrons credentials are    valid, whether that be a password or an authentication token    contained in request headers.

In some embodiments, the on-premise database is a relational databasethat includes patrons' personal information and identifying businesslogic identifiers in order to track the patrons' actions throughout theecosystem. In some implementations, data can be stored with encryption,such as, for example, AES-256 encryption, and integrates with akey-brokerage system via the API helping to ensure the key is not storedwith the hardware. This can help to ensure that even with a full breachof physical security including theft of the hardware, confidential datais not disclosed. In the event of simultaneous power and internefailure, manual recovery procedures and keys can be distributed toproperties.

In some embodiments, on-premise backend components are a self-containedmanaged application stack that can include, for example, a Kubernetesapplication controller, one or more application services, a databaseengine, and a configuration communicatively coupled to a related casinomanagement system and other services.

In some instances, the on-premise servers or instances can store datausing AES-256 full-disk encryption. Encryption keys can require 2-factorauthentication before allowing the system to start up. Management ofthis can be performed in conjunction with an IT-team. Booting theon-premise system components can involve passing one of two available2fa checks. If internet access is available, this can be provided by acheck of a source public IP address and a local encrypted keyfile. Inthe event internet access is not available, the system may be booted byinserting a provided hardware security key and entering a passphrase atstartup.

During normal boot, the on-premise servers or instances can request aKey-Encryption-Key (KEK) from the API services. In some implementations,the API services validate the server requesting the key as well ascompare the requesting IP address against a list of known-valid IPaddresses for that server. Provided the checks pass, the KEK is providedto the on-premise server. This can then be used to decrypt a localencryption keyfile which can then be used to decrypt the disk. Both theKEK and decrypted keyfile can discarded from memory prior to the bootprocess proceeding.

In the event the API services cannot be contacted, or if the public IPaddress has changed, the system can be provided an alternate 2fa bootcredential. Along with the on-premise servers or instances, a hardwaresecurity key and passphrase can be provided.

In some embodiments, application access is performed over HTTPS with thenetwork configuration provided by, for example, an IT department. If theoperator has HTTPS certificates and internal domains, these may bepre-loaded on the system. Otherwise, self-signed HTTPS certificates canbe used. The customer may explicitly accept these certificates in orderto access applications. Unless hostnames are provided by the operator,default host names can be used and can be added to a hosts file or localDNS configuration.

In some instances, the on-premise servers or instances involves accessto certain APIs, which may be located on or off-premise depending oncustomer configurations. In addition to access to these APIs, amanagement VPN can be created to allow for updates and systemsmanagement.

Referring now to FIG. 5 and FIG. 6, in some embodiments, one or moreengines or services perform the various operations of the credit wagersystem with loan and warrantying 200. The core services layer 505 caninclude, for example, one or more of a messaging service 605, loggingservice 610, encryption services 620, and a communication engine 615.The credit application services layer 510 can include one or more ofauthentication services 625, credit application processing engine 640, afee calculation engine 630, a credit access service 645, an externalsystems connector service 635, and a credit account management service650. In some instance, a compliance service layer 515 includes one ormore of a suspicious activity monitoring engine 655, a currencytransaction monitoring engine 665, a compliance reporting service 660,and a compliance filing service 670. In some implementations, an accountservices layer 520 includes one or more of a credit account transferservice 675, a credit packaging engine 680, a reconciliation engine 685,and a transfer billing service 690. In some embodiments, a responsiblegaming service 525 provides configurable credit allocation to supportresponsible gaming practice or compliance.

In some embodiments, the credit line may be funded in advance of play,while the player is in the casino, or during play, either on request ofthe player before play commences or while the player is engaged inwagering and is in need or want of credit. The player may make therequest through the gaming machine, through a gaming machine peripheral,at a kiosk, at a cashier window, on a mobile device, or at or throughsome other suitable point of contact or interface. A decision whether toextend credit may be made by casino management or by other casinoemployees or by another party that may be paid by the casino or theplayer for providing this service, or by a warrantor. The decision maybe made automatically by computer or other suitably programmed machinethat in some embodiments may automatically obtain and evaluateinformation about the player such as a credit report. If the casino orwarrantor decides not to extend credit, the player may fund the playwith cash. If the casino decides to extend credit, a credit limit is setand entered into a database along with a player identification, and acredit account is created for the player. If a fee is charged forcredit, the credit fee is added to the player's credit obligation, or insome embodiments the player may opt to pay this fee in cash or someother way. The player may then fund the play with credit or in someembodiments with more cash or a combination of cash and credit. In someinstances, an intermediate wager account holds allocated wager credit.

In some instances, the player submits a request for a credit line inadvance of arriving at the casino. In some embodiments a message is sentto the player advising that a fee will be assessed. Such notice can beprovided as part of the initial credit application rather than byseparate message. In some implementations, if the player does not agreeto the fee, the process ends. In some embodiments, no fee is charged forthe initial application. If the request is not approved, optionally amessage to that effect may be sent to the player and the process ends.Otherwise, a credit limit is set based on financial or other informationprovided by the player or as determined by the casino without playerinformation, the credit limit and a player identification are entered ina database, and a credit account, wager account, or both are created forthe player. In some embodiments the initial wager account balance iszero. In some embodiments the database is contained within a gamingdevice, at a server location in the casino, or in another location asmay be convenient, or the database may be maintained by another partyand accessed by the casino by electronic or other suitable communicationinterface.

In some embodiments the credit line may be funded in advance of beingused by the player. If the casino's own funds are to be used, the fundsare made available. Otherwise the funds are made available from a partyother than the casino, such as a warrantor. For example, a lender suchas a bank, finance company, small-loan company, or the like may committo advance funds against a credit line. In some embodiments such anadvance could be done all at once in the entire amount of the creditline, the advance being credited to the casino's account. The fundswould then be transferred from the casino's account to the player'saccount in amounts and at times as needed by the player, for example asrequested by the player or as determined by the casino. In otherembodiments the funds would be disbursed from the lender only as theplayer actually uses them for wagering. In yet another embodiment, anintermittent reconciliation occurs transferring funds between thewarrantor and the casino based on the credit balance of a single player,or alternatively, based on an aggregated balance of credit across a setof players.

Referring now to FIG. 7A, in some embodiments, while a player is engagedin game play 700, a player requests a line of credit 705 through anat-game interface, such as through a gaming device interface, a SMIB, amobile device, or the like. This request can be communicated to thecredit application services layer 510 of the wager credit managementservice 205 via the messaging service 605. The fee calculation engine630 can determine, based on input factors, fee requirement and amountrules, or both, whether a fee is required and if so, the amount of therequired fee 710. In some embodiments, a fee can include one or more ofan application fee, a scoring fee, an external service fee, aconvenience fee, or the like. Once the fee determination is made, if afee is required, the credit application processing engine 640 caninitiate a process generating a fee prompt view for display at theplayer interface 715. A fee acceptance input is received at the playerinterface, indicating whether or not the fee is authorized 720. If it isdetermined that the fee is not authorized 725, the credit applicationprocess ends 727 and the player can continue play with existing funds orthrough the addition of cash. If it is determined that the fee isauthorized 725, the credit application processing engine initiates thecredit application process 730, which can include collecting informationfrom the player directly through the player interface, collectinginformation from other sources such as an internal or external database,performing credit checks through interfacing with third-party creditservices, requesting credit approval from a warrantor, or the like, andmaking a determination based one or more of the aforementioned factorswhether or not to extend credit 735. If the credit applicationprocessing engine 640 determines that credit will not be extended,credit application processing engine 640 can initiate generating acredit denial view for display at the player interface 740. At thispoint, the game will continue to operate in its current state 745, suchas a credit-less, cash-only state.

Referring now to FIG. 7B, in some embodiments, one or more transactionfees are allocated to particular entities based, at least in part,request type, request amount, or both 711. If it is determined thatthere are no fees required, then the transaction fee required variableis set to false 712. If transaction fees are required, a determinationis made whether or not the fee is chargeable 713. If it is notchargeable, then the transaction fee required variable is set to false714. If it is chargeable, then it is determined whether or not theplayer is to be charged the fee 716. If the player is to be charged,then the fee amount is added to the transaction fee variable 717, andthe transaction fee required variable is set to true 718. If it isdetermined the player is not to be charged, then it is determinedwhether or not the casino is to be charged 719. If so, the transactionfee amount is added to the aggregate pending casino fee charge variable721.

Referring now to FIG. 7C, in some embodiments, one or more of creditapproval, maximum credit amount, or both, are determined, at least inpart, based, at least in part, on data received from one or moreexternal systems 216 (e.g., see FIG. 2), such as a third party creditscoring system 213, credit screening system 212, verification system206, or the like. The processing of a credit application request canbegin by retrieving applicant's scoring data input values 781, such as,for example, one or more of the applicant's first name, last name,social security number, driver's license number, driver's licenseinformation, age, email, bank account information, address, and thelike. Some or all of the retrieved applicant's scoring data input valuescan be marshalled and transmitted to one or more external system 783.Upon completion of third-party external processing activity, the creditwager system with loan and warrantying receives from the external system216 one or more scoring data output values associated with one or moredata scoring input values 785. Scoring data output values can include,for example, FICO scores, non-FICO credit scores, such as an iPredictscore, and the like. These scores can be use alone or in combination tocalculate a first application score value, in certain cases, by applyingone or more additional weighting factors to one or more of a scoringdata output values 787.

In some embodiments, additional scoring data values are retrieved. Suchvalues can include, for example, one or more of player club enrollmentstatus, player gaming history, bank account automated direct debitauthorization status, prior funds advancement, player employment status,player income source verification, player ]fungible assets on depositwith linked financial institution and account pay down activity, fullFICO report status, and the like 789. In some instances, a secondapplication score value is calculated based, at least in part, on theone or more additional scoring attributes 791. In some instances, afinal application score is calculated based at least in part on thefirst application score. In other embodiments, a final application scoreis calculated based at least in part on the second application score. Instill other embodiments, a final application score is calculated basedat least in part on the first application score and the secondapplication score 793.

In some implementations, one or more score-to-credit approval schedulesare retrieved 795 (e.g., see FIG. 94 through FIG. 97). For each approvalschedule credit amount of the applicable schedule, the final applicationscore is used to determine a maximum approvable credit amount 797, andthe maximum approved credit amount is set to the determined maximumapprovable credit amount 798. If the maximum approved credit amount isgreater than zero, the approval status is set to true 799.

In some embodiments, multiple pre-defined approval tiers definerequirements for players to obtain approval and advances for increasedcredit limits. These tiers can follow the same process described in FIG.7C, but with one or more of different preconditions, receiving differentexternal system outputs, receiving different additional scoring datavalues, applying different thresholds or schedules, or the like. FIG. 94through FIG. 97 provides an example of a set of a tiered credit approvalschedules. Pre-conditions for a first tier could include for example,one or more mandatory requirements, such as, existing enrollment in acasino player's club system 207, receipt of acceptable output from anidentity verification system 206, receipt of acceptable output from afraud verification system 209, minimum score from a credit scoringsystem 213, a minimum age, such as 21 years or older, and acceptance ofone or more contractual conditions, such as acceptance of system termsand conditions, privacy policy, and the like. Approval for additionaltiers can include one or more additional requirements, such asauthorized direct debit from a bank account, receipt of acceptableoutput from a credit screening service 212, prior history of havingutilized all existing available credit by advancing of funds to a wageraccount, prior history of having fully paid down a fully used availablecredit, and receipt of acceptable output of a full FICO credit bureaureport from a credit screening system 212.

In some embodiments, if instead, the credit application processingengine 640 determines that credit will be extended 735, the creditapplication processing engine 640 can initiate a credit limitcalculation determination process 750 determining the maximum creditavailable. In some instances, the maximum amount is authorized forautomatic allocation to an existing or new credit account. In otherinstances, the player is prompted to select an authorized amount up tothe maximum amount. In some instances, a maximum approval credit amount(e.g., see FIG. 7C) is displayed as the maximum selectable amount or themaximum amount. If it is determined a credit account does not exist 755,one or more of a credit account is created 760, a general wager accountor game-specific wager account may be created 765, or both. Once thecredit account is created the credit limit is set 770. The credit limitcan be set in various ways, including, for example, automatically basedon a credit allocation rule, such as allocating the maximum authorizedamount, or through a combination of a player's credit score combinedwith their gaming history or through receipt of a credit amountselection less than the maximum authorized amount received from an inputtransmitted from the player interface to the credit applicationprocessing engine 640.

In some embodiments, once the credit application process is completedand funds are approved, some amount of the available credit can beaccessed through the credit access service 645, added to the wageraccount 775, and deducted from the available credit of the creditaccount. Any transaction fee amount required 710 can be deducted fromthe wager account at the time the funds are added to the wager account780. Alternatively, the player can provide payment of the fee by anothermeans unrelated to the wager account.

Referring now to FIG. 8, in some embodiments, a player requests a lineof credit in advance of engaging in game play 800. This process issimilar to the process described for requesting credit while a player isengaged in game play 700 with a few variations. For example, the requestis received in advance of game play, 805, which means the request canoccur off-premise, and can utilize additional interfaces, such as byvoice phone, computer, written application, and the like. Also, where arequired fee is not authorized, the credit application process simplyends without any return to game play 810. Also, the transaction fee canbe received by methods other than reducing available funds in a wageraccount, such as by electronic payment from a banking or funds account815.

Referring now to FIG. 9, in some instances, a warrantor participates inone or more of the credit approval process, funds issuance process, andcredit account ownership 900. Initially, a credit-approval processoccurs that results in an approval 905. This approval process can bebased on factors and rules directed by the casino operator, thewarrantor, or both. In some instances, a warrantor owns the creditaccount and associated accounts receivable from the point of creditaccount creation. If it is determined that the credit account iswarrantor-owned 910, funds can be transferred to the casino operator 920to support the allocation of funds to player wager accounts. The amountof funds transferred from the warrantor to the casino operator candepend, at least in part, on a transfer fund policy, such as, forexample, an immediate transfer of a full amount, an immediate transferof a partial amount based on a credit threshold, a delayed transferbased on an intermittent schedule, a discounted transfer amount, and thelike 915. In some embodiments, where it is determined that the creditaccount is not warrantor-owned 910, the operator can fund advancerequest from an operator-funded operator account 925.

Upon detection of a fund advance request 930 at the credit accessservice 645, funds can be advanced to the associated wager account 935by the credit account management service 650. If it is determined thatthe fund advance request is in excess of a pre-determined operatoraccount threshold amount, the exceeding of which requires additionalfunding from a third party 940, transfer amounts can be requested fromand transferred from a warrantor to the casino operator 920. Thewarrantor can be an existing warrantor with a participation interest inthe credit account, or in case of an operator-owned credit account, thewarrantor can be a new warrantor.

Once there are no additional funds required to meet the funds advancerequest 930, the fee calculation engine 630 determines whether or not atransaction fee is due 945. In some instances, the fee is calculatedintermittently based on funds advance over a time period, such astwenty-four hours. If there is a fee due, then the wager account wherethe funds are advanced is adjusted down by an amount equal to thetransaction fee 950. When a credit account transfer request is detected955 at the credit account transfer service 675, the discount factor forthe receiving warrantor is retrieved 960 and the credit accountownership is transferred to the warrantor 965. The transfer billingservice 690 generates a billing event for the credit account 970,accounting for the determined discount factor if applicable, andeffectuates the billing through a pre-determined process, such as partof a reconciliation process.

Referring now to FIG. 10 and FIG. 11, in some embodiments, one or bothof wager advance thresholds or credit approval amount thresholds can beused to throttle the access to and advancing of funds to players, suchas for the purpose of promoting responsible gaming behaviors, complyingwith one or more laws or regulatory requirements, or reducing risk offinancial loss to one or more of the player, casino, or warrantor.

Referring first to FIG. 10, in some embodiments, the credit wager systemwith loan and warrantying supports promotion or enforcement of one ormore responsible gaming behaviors, such as, through the use of wageradvance thresholds 1000 set and monitored at the responsible gamingservice 525. One or more pre-determined credit thresholds can be setbased on factors determined to be relevant to throttling game play 1005.It could be determined that based on factors such as, for example, therate of play, the amount wagered, the current credit balance, pastgaming behavior, financial well-being, and the like, a credit-per-periodthreshold of $1,000.00 is set. That period could be, for example aone-hour lock period 1010, or could be set to period mandated by aregulatory body. Similarly, there could be additional thresholds withvarying locking periods, such as, a 48-hour locking period once anadvanced credit threshold of $10,000.00 is reached within a 24-hourperiod.

In some embodiments, the start time is set when a player places a firstwager 1015 and a lock is set restricting credit advances to a maximumamount equal to a first threshold amount 1020. In other instances, thestart time is set when a player first advances funds from a creditaccount to a wager account. One or more lock periods are retrieved 1025,the current time is retrieved repeatedly during game play at regularintervals 1030, and a determination is made if time has passed in excessof the one or more lock period 1035. Where the time that has passed fromthe start time to the current time exceeds a given lock period, thatlock is removed 1040. Where the lock is not removed, the ability toadvance funds in excess of the threshold is restricted.

Referring now to FIG. 11, in some embodiments, the credit wager systemwith loan and warrantying utilizes credit approval amount thresholds tothrottle gaming behavior 1100 set and monitored at the responsiblegaming service 525. One or more pre-determined credit approvalthresholds can be set based on factors determined to be relevant tothrottling game play 1105. An approval required setting can be set totrue for credit requests exceeding one or more credit amount thresholds1110. When a funds advance request is detected 1115, the total creditline advance amount is retrieved 1120. The total credit for purposes ofdetermining approval requirements is the sum of the total credit lineadvance amount and the funds advance amount requested 1125. Creditapproval thresholds are retrieved 1130, and if it is determined that thenearest credit amount threshold less than this summed total creditamount is approved 1135, then funds can be advanced 1140. If not, thenan approval process is initiated 1145. In some instances, like the wageradvance thresholds mechanisms 1000, the credit approval thresholds canbe used with associated locks to throttle play, avoiding the need to gothrough the credit approval process until such credit is needed.

In some instances, services support and facilitate intermittentreconciliation of credit accounts held, owned, or participated in, inwhole or in part, by one or more warrantors and one or more casinos.Referring now to FIG. 12, in some embodiments, a reconciliation engine685 preforms reconciliation of funds advanced between a warrantor and anoperator based, at least in part, on intermittent analysis of playercredit account balances, either individually or in the aggregate 1200.In some embodiments, the last reconciliation even log entry is retrievedfrom a data store 1205. It is parsed such that the data/time of the logentry is determined 1210, and the start date/time reconciliationvariable for the reconciliation process is set to the parsed date/timevalue 1215. The end date/time reconciliation variable for thereconciliation process is set to the current date/time value 1220, or incertain instances, a selected date/time value, and all credit advanceevent records to wager accounts between start reconciliation date/timeand end reconciliation date/time are retrieved 1225. The total creditadvance amount for the reconciliation period is calculated and set bysumming the credit advance amounts for all event records retrieved 1230.All credit line adjustment and pay down event records are retrieved forthe same reconciliation period 1235, and the total collection amount iscalculated and set as the sum of adjustment and pay down amounts for alladjustment and pay down records retrieved 1240. The amount of theaggregate pending fee payments chargeable to the casino is retrieved1242. Reconciliation amount for the reconciliation period is set to thetotal credit advance amount minus the total collection amount 1245. Ifits determined that the reconciliation amount is greater than zero 1250,then the reconciliation amount minus the aggregated pending casino feecharge is transferred from warrantor account to the operator account1255. Alternatively, if its determined that the reconciliation amount isless than zero 1250, then the reconciliation amount plus the aggregatedpending casino fee charge is transferred from operator account to thewarrantor account 1260. It will be appreciated by one skilled in the artthat reconciliation calculations can be adapted based on other factorsand business arrangements.

Referring now to FIG. 13 through FIG. 15, in some embodiments, one ormore services provide suspicious activity and currency transactionmonitoring and reporting, such as, for example, one or more of forcurrency transactions exceeding threshold amounts, structuredtransactions, and minimal gaming activity. In certain instances, reportsare automatically generated, automatically filed, or both.

Referring now to FIG. 13, in some instances, the currency transactionmonitoring engine 665 detects a wager account pay down event 1305. Thestart time is set to the date/time of the wager account pay down event1310, and all wager account pay down events that occurred during the 24hour period prior to the start time are retrieved 1315. Currencytransaction total is set to the sum of the retrieved wager account paydown event amounts 1320. If it is determined that the currencytransaction total is less than, for example, $10,000.00 1325, notransaction reporting alerts or reporting occurs 1330. Alternatively, ifit is determined that the currency transaction total is greater than,for example, $10,000.00 1325, transaction reporting alerts, reporting,or both occur. Reporting alerts from the compliance reporting service660 can include, for example, transmitting a Currency Transaction Reportnotification alert 1335. Reporting can include, for example, retrievingthe player's name, social security number, and driver's license number1340 and in some implementations, preparing, for example FINCEN Form 103Current Transaction Report for Casinos 1345. In some embodiments, acompliance filing service 670 facilitates automatic, or semi-automatic,filing of such reports 1350.

Referring now to FIG. 14, another example of compliance activitiesincludes monitoring for and detection of structured transactions 1400.In some instances, the suspicious activity transaction monitoring engine655 detects a wager account pay down event 1405. The start time is setto the date/time of the wager account pay down event 1410, and all wageraccount pay down events that occurred during a 14 day period prior tothe start time 1415. Currency transaction total is set to the sum of theretrieved wager account pay down event amounts 1420. If it is determinedthat the currency transaction total is less than, for example,$10,000.00 1425, no transaction reporting alerts or reporting occurs1430. Alternatively, if it is determined that the currency transactiontotal is greater than, for example, $10,000.00 1425, transactionreporting alerts, reporting, or both occur. In some instances, thesuspicious activity monitoring engine 655 transmits a possiblesuspicious activity alert notification 1435. If it is determined thatthe transactions do not constitute reportable structured transactions1440, then no further action is taken 1445. If it is determined that thetransactions do constitute reportable structured transactions 1440, theplayer's name, social security number and driver's license number areretrieved 1450, and in some instances, the compliance reporting service660 prepares the appropriate reports, such as the FINCEN Form 102Suspicious Activity Report by Casinos and Card Clubs 1455. In someembodiments, a compliance filing service 670 facilitates automatic, orsemi-automatic, filing of such reports 1460.

Referring now to FIG. 15, another example of compliance activitiesincludes monitoring for and detection of minimal gaming transactions1500. In some instances, the suspicious activity transaction monitoringengine 655 detects a large wager account or credit line pay down event1505 and a large cash out event 1510. The suspicious activitytransaction monitoring engine 655 then determines based on apre-determined ratio thresholds if gaming activity was minimallyproportional to the pay down amounts and cash out amounts 1515. If thatdetermination is that it is proportional, then no transaction reportingalerts or reporting occurs 1520. If that determination is that it is notproportional, then in some instances, the suspicious activity monitoringengine 655 transmits a possible Minimal Gaming with Large Transactionssuspicious activity alert notification 1525. In some embodiments,further determinations are made as to whether transactions constituteother reportable transactions 1530. If no other reportable transactionconditions are identified, no transaction reporting alerts or reportingoccurs 1535. If it is determined that the transactions do constitutereportable structured transactions 1530, the player's name, socialsecurity number and driver's license number are retrieved 1540, and insome instances, the compliance reporting service 660 prepares theappropriate reports, such as the FINCEN Form 102 Suspicious ActivityReport by Casinos and Card Clubs 1545.

In some embodiments, one or more approaches are available for the usethe win/loss aggregate game period settlement pool for settlement andthe sharing of wager loss collection percentages between the operatorand the warrantor. Referring now to FIG. 16, players wager individuallyand over a gaming period. The credit wagering system with loan andwarrantying gathers those outcomes into a win/loss aggregate game periodsettlement pool and settles to the operator based on the losses overthat game period time. The operator advances money to players, but atthe end of the game period, there is typically a net aggregate loss lessthan 100% of the advanced amounts. Settling, typically at a discountedrate, is a discounted level of the advances made to the individualplayers. In certain instances, the operator is the originator and thewarrantor buys a participation interest in the daily receivables at adiscount of the originated aggregated advance pool, with such purchasepotentially funded by the warrantor, a downstream licensed financepartner, or both.

In some instances, the warrantor buys the receivables and is wholly atrisk.

In yet other instances, the warrantor or a licensed finance partnermakes a consumer loan to a player that may be, for example, interestfree, subject to interest, or subject to a fee, and settles with theoperator for the actual discounted loss.

In some implementations, credit wagering system with loan andwarrantying is directly or indirectly engaged in one or more of twodistinct independent transactions, namely, a first independenttransaction that funds a wagering account (the transaction being betweenthe player and the third party warrantor or licensed finance partner),and a second independent transaction between the operator and thewarrantor where the warrantor buys a participation interest in accountsreceivable (the losses ascertainable from the win/loss aggregate gameperiod settlement pool) generated at the end of each game period.

In some embodiments, the variables include n number of players provideda consumer advance over a period of time representing a game period.Amounts funded move to the players' cashless wagering account and can,in some instances, only be used for wagering activity. The warrantorgives the operator a discounted percentage of the actual lossesascertainable from the win/loss aggregate game period settlement pool.On the game period settlement day, the actual game period losses mightbe, for example, 90% of the amount funded for that game period. Thewarrantor funds a discounted percentage of that by buying a position inthe receivables of the operator (e.g., 80%), such that the warrantor iseffectively funding, in this example, 72% of the actual advanced fundson the day of game period settlement with the operator. In someembodiments, the warrantor has full and sole responsibility forrecovering from the players. The warrantor might apply interest to latepayments. The warrantor then pays back to the operator a revenue sharefor funds above, in this example, the 80% game period settlement.

In some embodiments, an operator, such as, for example, a casino,originates advances to players 1605. A player then uses at least aportion of these advances to fund wagering activity during a gamingperiod 1610, where that gaming period can extend from, for example, agaming session to a period of days, weeks, months, or the like. The winsand losses for the gaming period can be aggregated into a win/lossaggregate game period settlement pool, that pool including one or moreof the individual wager winnings or losses for each player for the gameperiod, the aggregated wager losses across at least some of the players,the aggregated game period player repayments, and a settlement accountfor funds transfers 1615. In some instances, a warrantor takes aparticipation interest in the aggregated game period wager lossreceivables 1620. In some instances, one or more of a warrantor orthird-party financer fund at least a percentage of the funds advancedover a game period 1625. This amount can be characterized as an initialpurchase price. At the time of settlement, the reconciliation engine 685(e.g., see FIG. 6) can accomplish a revenue share with respect to therealization and collection of wager losses, where the operator receivesa discounted percent of Aggregate Game Period Wager Losses−the InitialPurchase Price 1630, and the warrantor receives a participation interestpercent of Aggregate Game Period Wager Losses−Initial Purchase Price1635.

Referring now to FIG. 17, in some embodiments, the credit wager systemwith loan and warrantying receives a player enrollment request 1705 anda player credit application 1710. It is determined based at least inpart on the credit application whether the player is approved for acredit advance 1715. Where the player is approved, a virtual wageraccount is created 1720 and an aggregate wager account balance ismaintained 1722 and the advance line amount is made available in thewagering account 1725. The credit wager system with loan and warrantyingreceives one or more player advance draw requests 1730. When a advancerequest is received, it is determined whether or not the amount is lessthan the present advance limit 1735. If it is over the advance limit,then a request is displayed directing the player to lower the advancerequest amount 1740. If the advance is less than or equal to the limit,the amount is advanced 1745 and the advance limit is adjustedaccordingly 1750 1755.

Referring now to FIG. 18, in some embodiments, the credit wager systemwith loan and warrantying receives a player wager request 1805 1810. Insome instance fees, such as a daily wager fee, are allocated to theplayer 1815. As the gaming period progresses, the win/loss aggregategame period settlement pool is adjusted to reflect the win or losscondition of the players 1820, and an aggregate game period wager lossescalculation is maintained or is otherwise available to be calculated1825. A warrantor funds the operator in an amount equal to the aggregategame period losses times a warranty discount 1830. The operator fundsvirtual wager accounts during the game period in an amount equal to theactual aggregated game period wager winnings 1835. The warrantor debitsthe virtual wager accounts in an amount equal to the actual game periodwager losses 1840. The warrantor allocates to the win/loss aggregategame period settlement pool, and collects one or more of the advancedraw amounts, advance fees, and wager fees from one or more players1845, 1850.

Referring now to FIG. 19A and FIG. 19B, examples are shown for the usethe win/loss aggregate game period settlement pool for settlement andthe sharing of wager loss collection percentages between the operatorand the warrantor.

In some embodiments, a mobile interface 310 (e.g., see FIG. 3) providescertain services to patrons, players, or both. Referring now to FIG. 20and FIG. 21, in some embodiments, upon initiation of the mobileinterface 310, an create account view 2000 is displayed, with controlsfor the collection of identifying credentials 2005, 2010, 2015 and forthe submission of collected identifying credentials 2020. API endpointscan include, for example, GET/Enroll/Lookup. The interface can collectidentifying credentials for marshalling and transmission, such as:

Example Data Input

  { “card_number”: “123456789”, “card_pin”: “1234” “date_of_birth”:“1985-12-12”, “property id”: “2” }

Upon receiving of identifying data 2105, the API endpoint of GET/Enroll/Lookup 2110 and the data input is passed to the authenticationservice. The authentication service then validates and checks theauthentication and user database to see if the user identificationcredentials correspond to a valid player 2115. If the useridentification credentials are verified, the authentication servicedetermines if the date of birth and pin are valid and correspond to theidentified stored player information 2120. If the correspondence isvalidated, the authentication service then marshals and returns the dataoutput 2125, 2130. If the correspondence is not valid, theauthentication service generates an error 2135. The authenticationservice then returns a failure message 2140.

Example Data Output

  { “name_first”: “John”, “name_last”: “Smith”, “property_id”: “2”,“player_card_program_id”: “2”, “card_number”: “123456789”, “street”:“123 Main St.”, “city”: “Las Vegas”, “state”: “NV”, “zip”: “89101”,“phone”: “7021234567”, “date_of_birth”: “1985-12-12”, “name”: “JohnSmith” }

Upon detection of Next button event associated with the create accountview 2000, the player information view is displayed 2200. Referring nowto FIG. 22 and FIG. 23, in some implementations, the player informationview 2200 includes one or more of controls for the display andcollection of player information 2205 through 2240, for consent andacceptance of terms 2245, and for the submission of collected playerinformation 2250. API endpoints can include, for example, GET/Property/PropertyID/Legal and POST /Enroll. The interface can collectplayer information data for marshalling and transmission, such as:

Example Data Input

  { “card_number”: “123456789”, “date_of_birth”: “1985-12-12”, “email”:“john@smith.com”, “property_id”: “2”, “password”: “password123”,“mobile”: “+17021234567”, “city”: “Las Vegas”, “street”: “123 Main St.”,“state”: “NV”, “zip”: “89123”, }

Upon receiving of player information data 2305, the API endpoint of POST/Enroll is called 2310 and the data input is passed to theauthentication service. The authentication service then validates andchecks the authentication and user database to see if the useridentification credentials correspond to a valid player 2315, 2320,2325. If the user identification credentials are verified, theauthentication service determines if the account exists 2330.Authentication credentials are then passed to the authentication service2335, and if validated 2340, a session token is generated and returnedalong with player information output data below 2345, 2350. If theaccount does not exist or if the authentication credential cannot bevalidated, the authentication service generates an error 2355 andreturns a failure message 2360.

Example Data Output

  { “id”: “10”, “property_id”: “2”, “player_card_program_id”: “2”,“player_card_number”: “123456789”, “email”: “john@smith.com”,“identity_verified”: null, “email_verified”: 1, “name_first”: “John”,“name_last”: “Smith”, “name”: “John Smith”, “date_of_birth”:“1985-12-12”, “name_middle”: null, “line1”: “123 Main St.”, “line2”:null, “line3”: null, “street”: “123 Main St.”, “sub_region”: null,“city”: “Las Vegas”, “region”: “NV”, “postal_code”: “89101”,“sorting_code”: null, “country_code”: “US”, “mobile”: “+17021234567”,“mobile_verified”: 1, “advance_line_type_code”: “accepted”,“advance_line_type_display”: “Accepted Line”, “advance_line”: “1000”,“bank_linked”: “0” }

Upon detection of Next button event associated with the playerinformation view 2200, the verify phone number view 2400 is displayed.Referring now to FIG. 24 and FIG. 25, in some implementations, theverify phone number view 2400 includes one or more of controls for thedisplay and collection of player verification information 2405 for thesubmission of a verification code received by, for example, sms 2410,and for the resending of a verification code 2415. API endpoints caninclude, for example, POST /Enroll/Verify-Mobile and POST/Enroll/Verify-Mobile/Resend. The interface can collect verificationcode information for marshalling and transmission, such as:

Example Data Input

  { “code”:“123456” }

Upon receiving of a verification code 2505, the API endpoint of POST/Enroll/Verify-Mobile is called 2510 and the data input is passed to theauthentication service 2515. The authentication service then validatesand checks the validity of the session token 2520, and if valid,proceeds determine if the validation code is valid 2525. In someimplementations, the code is further verified to determine if it has notbeen used, if its use time limit has expired, or both. If it isdetermined that the code has neither expired nor has been used before,the verification code status is set to used 2535 and the phone numberstatus is set to verified 2530. A verification equal to true message isthen generated and returned. If it is determined that the code hasexpired or has been used before, an error is generated 2545 and an errormessage returned 2550.

In certain instances, upon detection of a click event associated withthe resend control 2415, the POST /Enroll/Verify-Mobile/Resend iscalled. Any previous sent codes are set to used, and a new valid code isgenerated and transmitted to the player via, for example, SMS.

In some embodiments, an additional identity verification occurs.Referring now to FIG. 26 and FIG. 27, if the additional identityverification is successful, no view is displayed. If the additionalidentity verification fails, an identity check failed view is displayed2600.

Where the additional identity verification occurs, API endpoints caninclude, for example, POST /Enroll/Identity/Start 2710. The interfacecan receive the following input:

Example Data Input

Session Token in the Header of the Request

The authentication service checks the validity of the session token2705, 2715, 2720 and if valid, proceeds determine if an additionalidentity verification was performed previously 2725. If it is determinedthat a check was not performed previously, an external authenticationservice API can be called 2730 by passing, for example, first name, lastname, date of birth, phone number, address, or other identifying data.If the external service verification is successful, identity verified isset to true 2735 and a value of true is returned 2740.

In some embodiments, a mobile interface 310 (e.g., see FIG. 3) providescertain account linking services. Referring now to FIG. 28 through FIG.30, in some embodiments, upon detecting an account linking requestevent, an account linking view 2800 is displayed, with controls forinitiating account link activity 2805. API endpoints can include, forexample, API's that interact with third-party account linking services,such as Dwolla, including, for example, POST /Enroll/Dwolla, POST/Enroll/Verify-Email/Resend, GET /Enroll/Dwolla/Iav/Load, and POST/Enroll/Dwolla/Iav/Completed. If it is determined that an associatedemail account has not yet been verified, an email not verified view isdisplayed 3000 and the user is not allowed to proceed.

Upon receiving the link request, the data and input is passed to theauthentication service. The authentication service then validates andchecks to determine if the session token is valid 2905, 2910, 2915,2920. If the token is valid, it is next determined if the customerexists in the external verification system 2925, and if not, a customeris created using the external verification system API 2930. An instantaccount verification token is generated using the external verificationsystem API 2935, which is then used to complete the account linkingprocess 2940. Once completed, link attempt ID and and funding source IDre received from the external service and stored in a data store, andthe account is identified as bank_linked 2955. If it is determined thatthe If it is determined that the session toke is not valid, an error isgenerated 2960 and an error message returned 2965.

In some embodiments, the enrollment process includes a location check, acredit check, or both. Referring now to FIG. 31 through FIG. 35, in someembodiments, a location check view is displayed 3110 to determinelocation to, for example, comply with state laws at least with respectto authorizing and completing the credit check. In some implementations,the API endpoint of GET /Geofence is called by providing the sessiontoken latitude, and longitude in the header request 3205, 3210. Thesession token is passed to the authentication service 3215 and it isdeterred whether the session token is valid 3220. If it is valid, thelatitude and longitude, in combination, are assessed as to whether ornot they are associated with a valid property 3225. If location iscorrect, valid_position is set to true 3230, and true is returned 3235.If the session toke is determined to be invalid or if the latitude andlongitude are determined not to be associated with a property, then anerror is generated 3240 and an error message is returned 3245.

In some embodiments, a credit check initiation view 3300 is displayed,with controls for collecting identification data, such as the last fourdigits of a social security number 3305, consent for a credit reportpull 3310, such as consenting to one or more of displayedproperty-specific or state-specific terms, and submission of averification request 3315. API endpoints can include, for example, GET/Property/PropertyID/Legal and POST /Enroll/advance-line/credit-check.The interface can collect location input date for marshalling andtransmission, such as a session token, latitude and longitude, andidentifying data collected, transmitted in the header of the request3505.

In some implementations, the API endpoint of GET/Property/PropertyID/Legal is called and retrieves legal documentsassociated with the relevant property 3505. The API endpoint GET/Enroll/advance-line us called and passes the data input as noted above3510. The session token is passed to the authentication service 3515 andit is determined whether the session token is valid 3520. If it isvalid, the latitude and longitude, in combination, are assessed as towhether or not they are associated with a valid property 3525. Iflocation is valid, it is determined whether an advance line has alreadybeen offered or accepted 3530. If a line has been offered or accepted, aresponse is returned 3535, 3540. If a line has not been offered oraccepted, identifying information such as the last 4 digits of thesocial security number, first name, last name, phone, address, date ofbirth, and like are passed to an external credit check API 3545. Creditqualification data is received 3550. Received credit qualification datais validated 3555 and if valid, and either alone or in combination withother data, an advance line amount is determined and offered based, atleast in part, on the credit qualification data 3560 3565.

Example Data Output

  { “id”: “10”, “property_id”: “2”, “player_card_program_id”: “2”,“player_card_number”: “123456789”, “email”: “john@smith.com”,“identity_verified”: null, “email_verified”: 1, “name_first”: “John”,“name_last”: “Smith”, “name”: “John Smith”, “date_of_birth”:“1985-12-12”, “name_middle”: null, “line1”: “123 Main St.”, “1ine2”:null, “1ine3”: null, “street”: “123 Main St.”, “sub_region”: null,“city”: “Las Vegas”, “region”: “NV”, “postal_code”: “89101”,“sorting_code”: null, “country_code”: “US”, “mobile”: “+17021234567”,“mobile_verified”: 1, “advance_line type_code”: “offered”, “advance_linetype_display”: “Offered Line”, “advance_line”: “2000”, “bank_linked”:“0”, }

Referring now to FIG. 34 through FIG. 37, if it is determined that noadvance line will be offered, a credit check fail view is displayed3400, which, in some instances, includes one or more explanations forthe advance line denial 3405, 3410. If instead, an advance line isapproved, an approve and accept view is displayed 3600 with controls forselecting the amount of the advance 3605, 3610, accepting or decliningof the advance along with the associated terms 3615, 3620, or both. APIendpoints can include, for example, GET /Property/PropertyID/Legal, GET/Enroll/advance-line, POST /Enroll/advance-line/accept, POST/Enroll/advance-line/decline. The interface can collect location inputdate for marshalling and transmission, such as a session token, latitudeand longitude, and identifying data collected, transmitted in the headerof the request.

In some instances, an API endpoint of GET /Property/PropertyID/Legal iscalled and retrieves the legal documents associated with the property3710. A call is then made to GET /Enroll/advance-line 3705, 3710. Thesession token is passed to the authentication service 3715. Theauthentication service then determines if the session token is valid3720. the latitude and longitude are validated to determine if theycorrespond to the property 3725. The advance-line-offer is returned anddisplayed, along with the available advance line amount. Upon detectionof an acceptance event 3730, the amount accepted is transmitted via acall to POST /Enroll/Advance-Line/Accept. The amount received isvalidated. In some instances, the amount accepted is validated against aset of required parameters such as, for example, whether or not theamount is divisible by 50, is greater than 100, or the like 3735. Oncethe advance line accepted amount is validated the accepted line with theaccepted amount is recorded in the database and a success message isreturned 3740. If the session token is invalid, the latitude andlongitude do not correspond to a property, the advance line is notaccepted, or the advance line does not conform to one or moreparameters, then an error is generated 3745 and an error messagereturned 3750.

Example Data Output

  { “advance_line_type_code”: “accepted”, “advance_line_type_display”:“Accepted Line”, “advance_line”: “1000”,}

Referring now to FIG. 38 through FIG. 65, in some embodiments, one ormore from a series of mobile views provides interfaces to variousfeatures, functions, and services of the credit wager system and methodof use with loan and warrantying including, but not limited to,enrollment views 3800, authentication views 3900, 4000, dashboard views4100, recent activity views 4200, todo views 4300, marker management andpayment views 4400, 4500, 4600, 4700, 4800, statement and transactionhistory views 4900, 5000, notification views 5100, setting views 5200,player info views 5300, 5400, 5500, 5600, linked bank account views5700, 5800, notification management views 5900, 6000, and legal terms,policies, and notices views 6100, 6200, 6300, 6400, 6500.

In some implementations, an at-machine interface, such as via a SMIB orembedded technology, provides one or more of account authorization,account access, credit request submission, credit approval notification,credit access, funds advancement, and fee authorization. Referring nowto FIG. 66 through FIG. 68, in some embodiments, a user interface canprovide a series of selections for account game management 6600,including interface controls to request a new credit line 6605, accessan existing credit line 6610, or both. Upon detection of a credit accessevent, an authentication event is initiated such as, for example,generating an account authorization view for authenticating creditaccount access 6700. Once received, the receiving device can communicatethe authentication input to the authentication service 625 (e.g., seeFIG. 6). If authentication is validated, the credit access service 645can control elements of credit access. The credit account managementservice 650 can provide credit management views 6800, displaying thecredit line total 6805, the available credit 6810, and one or morecontrols for initiating fund advancement functions 6815.

Referring now to FIG. 69 and FIG. 70, in some embodiments, upondetection of a credit request event, a credit line request view can bedisplayed 6900. In some embodiments, a series of authorizationacknowledgement prompts can be provided, such as, for example, anacceptance of terms 7005, an acceptance of fees 7010, and anauthorization to use available information to perform credit applicationprocessing activities 7015.

Referring now to FIG. 71 to FIG. 77, in some embodiments, a mobiledevice app provides one or more of credit request submission, creditapproval notification, account access, credit access, funds advancement,fee authorization, and funds transfer confirmation. An accountregistration view 7100 can collect identification and authenticationcredential information, as well as information used in creditapplication processing. In some embodiments, this can include one ormore of first name 7105, last name 7110, mobile number 7115, email 7120,and social security number 7125. In some instances, there is aninterface to one or more of receive, scan, and transmit a driver'slicense 7130. In some embodiments, a series of authorizationacknowledgement prompts can be provided, such as, for example, anacceptance of terms 7135, and an acceptance of fees 7140.

In some instances, a view is available confirming the authorization of acredit line 7200, which can include, for example, a credit score 7205,an authorized maximum credit amount 7210, and a control to accept theavailable credit line 7215. Once acceptance is detected, an interface tothe credit account management service 650 (e.g., see FIG. 6) functionscan be displayed 7300, providing controls to, for example, view offeredavailable credit 7305, view the offered credit limit 7310, and acceptmarker 7315. Upon detection of an accept maker control event, a view canbe displayed for drawing an amount of credit. Controls can include, forexample, an amount to be advanced display 7405, a post-advance availablecredit display 7410, fixed advance amounts 7415, and an initiate advancecontrol 7420. In some embodiments, the advance amount is immediatelyavailable for game play on a particular gaming machine. In anotherembodiment, the advance amount is advanced to an intermediate container,such as a unified wallet, for use in particular game play. In otherembodiments, the advance amount is advance to a player account which maybe cashed out in whole or in part. In certain implementations, theapplication of fees is triggered, at least in part, by the drawing offunds against the accepted marker. In still other embodiments, thefunding amounts to an intermediate account by advances drawn against anaccepted marker, may be automatically available to a player during gameplay at a gaming device or instance.

In some embodiments, a fixed transaction fee acceptance view isdisplayed 7500. In another embodiment, a percentage of amounts advancedacceptance view is displayed 7600. In some implementations, acceptanceof fees, such as transactions fees, is agreed to prior to advancingamounts, such as during the setup of the player account, throughacceptance of general terms of use, through a one-time acceptance priorto the first advance, or the like. In certain instances, fees aredetermined intermittently rather than at the moment that funds areadvanced against an accepted marker. For example, fees can be calculatedas a percentage of amounts advanced based on the maximum amount advancedat any given time over a twenty-four hour period. In someimplementations, upon completion of the funds transfer, a confirmationview is displayed 7700.

In some embodiments, a dashboard interface 330 (e.g., see FIG. 3)provides certain services to property operators, system operators,warrantors, and the like. Referring now to FIG. 78 and FIG. 79, in someembodiments, upon initiation of the dashboard interface 330, anauthentication view 7800 is displayed, with controls for the collectionof authentication credentials 7805, 7810, and for the submission ofcollected credentials 7815. API endpoints can include, for example, POST/Authenticate and GET /Authenticate. The interface can collectauthentication credentials for marshalling and transmission, such as:

Example Data Input

  {  “email”:john@smith.com  “password”:”password123” “Biometric; facialrecognition, thumbprint, retinal scan” “Out of Wallet Challenge”: “TextPIN validation” }

Upon receiving of credential data 7915, the API endpoint of POST/Authenticate is called 7920 and the data input is passed to theauthentication service. The authentication service then validates andchecks the authentication and user database to see if the useridentification credentials are valid 7925. If the user identificationcredentials are verified, the authentication service determines if thepassword is valid for the identification credential 7930, 7935. If thecredentials are valid, the authentication service generates a sessiontoken 7950. The authentication service then returns the data outputalong with the session token as a cookie 7955. If the credentials arenot valid, the authentication service generates an error 7940. Theauthentication service then returns an authentication failure message7945. A GET request uses the session token to get the user's informationwith the same output.

Example Data Output

  { “id”: “2”, “company_id”: “1”, name”: “John Smith”, “title”: “ProjectManager”, “email”: “john@smith.com”, “role”: “superadmin”,“role_display”: “Super Admin”, “company”: “Marker Trax”, “suspended”: 0}

Referring now to FIG. 80 and FIG. 81, in some embodiments, uponsuccessful authentication, the dashboard interface 330 can display anoperator list view 8000, with controls for searching 8005 and forlisting results 8010. API endpoints can include, for example, GET/Operator/List.

Example Optional Data Input

  { “sort”: “patrons”, “direction”: “DESC” }

Upon receiving an operator list view request event 8105, the APIendpoint of GET /Operator/List is called 8110 and the data input ispassed to the account services layer 520 (e.g., see FIG. 5). If thesession token is valid 8115, the account service then validates andchecks the database for the optional fields if they were passed. Ifvalid operators exist in the database 8116, the account services layerwill validate and filter based on the optional fields passed 8117. Ifthe operators were successfully validated. the API retrieves and returnsthe operator data output below 8130, 8135, otherwise an error isgenerated 8120 and returned 8125.

Example Data Output

  { “totalCount”: “2”, “queryTime”: 1595521613, “start”: 0, “limit”: 10,“sort”: “patrons”, “direction”: “DESC”, “filter”: “”, “operators”: [  {  id”: 3,   “display”: “One Casino & Resort”,   “code”: “one_casino”,  “created”: 1568169919,   “users”: “2”,   “patrons”: “7”  },  {   “id”:2,   “display”: “Another Casino”,   “code”: “another_casino”,  “created”: 1568169919,   “users”: “6”,   “patrons”: “4”   }  ] }

Referring now to FIG. 82 and FIG. 83, in some embodiments, uponsuccessful authentication, the dashboard interface 330 can display anoperator detail view 8200, with controls for searching 8205 and forlisting results 8210. API endpoints can include, for example, GET/Operator/{Name}.

Example Optional Data Input

  { “sort”: “patrons”, “direction”: “DESC” }

Upon receiving an operator detail request 8305, the API endpoint of GET/Operator/{Name} is called 8310 and the data input is passed to theaccount services layer 520 (e.g., see FIG. 5). If the session token isvalid 8315, the account service then validates and checks the databasefor the optional fields if they were passed. If operator name is in thedatabase 8316, the API retrieves and returns the operator detail dataoutput below 8330, 8335, otherwise an error is generated 8320 andreturned 8325.

Example Data Output

  {  “id”: 3,  “company_type_id”: 2,  “code”: “one_casino”,  “display”:“One Casino & Resort”,  “created”: 1568169919,  “updated”: 1568169919, “deleted”: “0”, “stats”: {  “users”: “0”,  “patrons”: “7”, “total_lines”: “7500”} }

Referring now to FIG. 84 and FIG. 85, in some embodiments, upondetection of an add user request event, the dashboard interface 330 candisplay an add user view 8400, with controls for collecting usermetadata 8405, 8410 and user role data 8415. API endpoints can include,for example, POST company/[companyNumber]/user.

Example Data Input

  {  “email”: “user@markertrax.com”,  “title”: “Rep”,  “name”: “SomeUser”,  “role_id”: “4” }

Session Token in the Header of the Request

Upon receiving new user request 8505, the API endpoint of POSTcompany/[companyNumber}/user. is called 8510 and the data input ispassed to the account services layer 520 (e.g., see FIG. 5). If thesession token is valid 8515, the account service then validates andchecks if the user already exists 8530. If the user is valid and doesnot already exist in the database, a new user record is added to theauthentication database 8535 and output data returned 8540, otherwise anerror is generated 8520 and returned 8525.

Example Data Output

  {  “id”: “10”,  “company_id”: “3”,  “name”: “Some User”,  “title”:“Rep”,  “email”: “user@markertrax.com”,  “role”: “o_manager”, “role_display”: “Manager”,  “company”: “One Casino & Resort”, “suspended”: 0 }

Referring now to FIG. 86 and FIG. 87 in some embodiments, upon detectionof a user detail request event, the dashboard interface 330 can displaya user detail view 8600, with controls for viewing and modifying userand role data 8605, 8610, 8615, setting passwords 8620, resettingpasswords 8625. setting user status 8630, and displaying user activityhistory 8635. API endpoints can include, for example, GETcompany/{company number}/user/{userID}.

Example Input

The companyNumber and userId are Passed as URL Parameters as a Part ofthe GET Request Session Token in the Header of the Request

Upon receiving user detail request 8715, the API endpoint of GETcompany/{company number}/user/{userID} is called 8720 and the data inputis passed to the account services layer 520 (e.g., see FIG. 5). If thesession token is valid 8725, the account service then validates andchecks if the user exists in the database 8726, the API retrieves andreturns the user detail data output below 8740, 8745, otherwise an erroris generated 8730 and returned 8735.

Example Data Output

  {  “id”: “10”,  “company_id”: “3”,  “name”: “Some User”,  “title”:“Rep”,  “email”: “user@markertrax.com”,  “role”: “o_manager”,“role_display”: “Manager”,  “company”: “One Casino & Resort”,“suspended”: 0 }

Referring now to FIG. 88 and FIG. 89 in some embodiments, upon detectionof a patron listing view request, the dashboard interface 330 candisplay a patron list view 8800, with controls for searching 8805 andfor listing results 8810. API endpoints can include, for example, GET/company/{companyNumber}/patron/list.

Example Input

  {  {companyNumber} as a URL parameter }

Session Token in the Header of the Request

Upon receiving a patron listing view request 8915, the API endpoint ofGET /company/{companyNumber}/patron/list is called 8920 and the datainput is passed to the account services layer 520 (e.g., see FIG. 5). Ifthe session token is valid 8925. Patron records, if any exist,associated with the company number/company id are retrieved 8940 and theoutput data returned 8945, otherwise an error is generated 8930 andreturned 8935.

Example Output

{  “totalCount”: “4”,  “queryTime”: 1595541008,  “start”: 0,  “limit”:10, “sort”: “name”,  “direction”: “ASC”,  “filter”: “”, “patrons”: [   {   “id”: “48”,    “property_id”: “1”,    “player_card_program_id”: “1”,   “player_card_number”: “123456789”, “email”: “john@gmail.com”,   “created”: 1593154404,    “email_verified”: 1,    “name_first”:“John”,    “name_last”: “Smith”,    “name”: “John Smith”   }   {   “id”: “46”,    “property_id”: “1”,    “player_card_program_id”: “1”,   “player_card_number”: “133456789”,    “email”: “user@markertrax.com”,   “created”: 1592550115,    “email_verified”: 1,    “name_first”:“Johnny”,    “name_last”: “Smith”,    “name”: “Johnny Smith”   }   {   “id”: “47”,    “property_id”: “1”,    “player_card_program_id”: “1”,   “player_card_number”: “143456789”,    “email”:“person@markertrax.com”,    “created”: 1592827434,    “email_verified”:0, “name_first”: “Jon”,    “name_last”: “Doe”,    “name”: “Jon Doe”   }  {    “id”: “45”,    “property_id”: “1”,    “player_card_program_id”:“1”,    “player_card_number”: “153456789”,    “email”:“wilson@markertrax.com”,    “created”: 1592006518,    “email_verified”:1,    “name_first”: “Wilson”,    “name_last”: “Smith”,    “name”:“Wilson Smith”   }  [ }

Referring now to FIG. 90 and FIG. 91 in some embodiments, upon detectionof a patron detail request, the dashboard interface 330 can display apatron detail view 9000, with controls for uploading documents 9005,changing advance line status 9010, resetting passwords 9015, changingpatron status 9020, displaying market and credit line status 9025,displaying patron metadata 9030, 9035, 9040, displaying account activity9045, and displaying marker history 9050. API endpoints can include, forexample, GET /company/{companyNumber}/patron/{patronId}.

Example Input

{companyNumber} and {patronId} as the URL parameters for the request

Session Token in the Header of the Request

Upon receiving patron detail request 9115, the API endpoint of GETcompany/{company number}/user/{userID} is called 9120 and the data inputis passed to the account services layer 520 (e.g., see FIG. 5). If thesession token is valid 9125, the account service then validates andchecks if the patron exists in the database 9126, the API retrieves andreturns the patron detail data output below 9140, 9145, otherwise anerror is generated 9130 and returned 9135.

Example Output

  {  “id”: “14”,  “property_id”: “2”,  “player_card_program_id”: “2”, “player_card_number”: “123456789”,  “email”: “john@markertrax.com”, “identity_verified”: null,  “email_verified”: 0,  “name_first”: “John”, “name_last”: “Smith”, “name”: “John Smith”,  “date_of_birth”:“1990-01-01”, “name_middle”: null,  “line1”: “123 Main St”, “1ine2”: “”, “1ine3”: null,  “street”: “123 Main St ”,  “sub_region”: null,  “city”:“Las Vegas”,  “region”: “NV”,  “postal_code”: “89123”,  “sorting_code”:null,  “country_code”: “US”,  “mobile”: “+7021234567”, “mobile_verified”: 1,  “drivers_license_verified”: null, “drivers_license_number”: null,  “drivers_license_expiration”: null, “drivers_license_state”: null,  “advance_line_type_code”: null, “advance_line_type_display”: null,  “advance_line”: null, “bank_linked: “0” }

Many different systems can implement the method of the credit wageringsystem with loan and warrantying. Moreover, the steps of the presentmethod could occur at different parts of a system, at a single part of asystem, in parallel across the system, or in any other fashion.Moreover, certain embodiments of the credit wagering system with loanand warrantying are described with reference to methods, apparatus(systems) and computer program products that can be implemented bycomputer program instructions. These computer program instructions canbe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the acts specified herein totransform data from a first state to a second state.

These computer program instructions can be stored in a computer-readablememory that can direct a computer or other programmable data processingapparatus to operate in a particular manner, such that the instructionsstored in the computer-readable memory produce an article of manufactureincluding instruction that implement the acts specified herein.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the acts specified herein.

The various illustrative logical blocks, modules, circuits, andalgorithm steps described in connection with the embodiments disclosedherein can be implemented as electronic hardware, computer software, orcombinations of both. The various illustrative logical blocks, modules,and circuits described in connection with the embodiments disclosedherein can be implemented or performed with a general purpose processor,a digital signal processor (DSP), an application specific integratedcircuit (ASIC), a field programmable gate array (FPGA) or otherprogrammable logic device, discrete gate or transistor logic, discretehardware components, or any combination thereof designed to perform thefunctions described herein. A general-purpose processor can be amicroprocessor, but in the alternative, the processor can be anyconventional processor, controller, microcontroller, or state machine. Aprocessor can also be implemented as a combination of computing devices,e.g., a combination of a DSP and a microprocessor, a plurality ofmicroprocessors, one or more microprocessors in conjunction with a DSPcore, or any other such configuration.

The blocks of the methods and algorithms described in connection withthe embodiments disclosed herein can be embodied directly in hardware,in a software module executed by a processor, or in a combination of thetwo. A software module can reside in RAM memory, flash memory, ROMmemory, EPROM memory, EEPROM memory, registers, a hard disk, a removabledisk, a CD-ROM, or any other form of computer-readable storage mediumknown in the art. An exemplary storage medium is coupled to a processorsuch that the processor can read information from, and write informationto, the storage medium. In the alternative, the storage medium can beintegral to the processor. The processor and the storage medium canreside in an ASIC. The ASIC can reside in a user terminal. In thealternative, the processor and the storage medium can reside as discretecomponents in a user terminal.

Referring now to FIG. 93, in one configuration, the credit wager systemwith loan and warrantying devices 9300 include a bus 9305 whichinterconnects major subsystems of computing device, 112, such as acentral processor 9310, a system memory 9315 (typically RAM, but whichmay also include ROM, flash RAM, or the like), an input/outputcontroller 9320, an external audio device, such as a speaker system 9325via an audio output interface 9330, an external device, such as adisplay screen 9335 via display adapter 9340, an input device 9345(e.g., remote control device interfaced with an input controller 9350),one or more USB devices 9365 (interfaced with a USB controller 9370),and a storage interface 9380. In some instances, the computing device112 includes one or more sensor s 9355 connected to bus 9305 through asensor controller 9360 and a network interface 9385 (coupled directly tobus 9305).

Bus 9305 allows data communication between central processor 9310 andsystem memory 9315, which may include read-only memory (ROM) or flashmemory (neither shown), and random access memory (RAM) (not shown), aspreviously noted. The RAM is generally the main memory into which theoperating system and logic instructions are loaded. The ROM or flashmemory may contain, among other code, the Basic Input-Output system(BIOS) which controls basic hardware operation such as the interactionwith peripheral components or devices. Instructions resident with thecredit wager system with loan and warrantying computing devices aregenerally stored on and accessed via a non-transitory computer readablemedium, such as a hard disk drive (e.g., fixed disk 9375) or otherstorage medium. Additionally, applications may be in the form ofelectronic signals modulated in accordance with the application and datacommunication technology when accessed via interface 9385.

Storage interface 9380, as with the other storage interfaces ofcontroller 9300, may connect to a standard computer readable medium forstorage and/or retrieval of information, such as a fixed disk drive9375. Fixed disk drive 9375 may be a part of computing device 9300 ormay be separate and accessed through other interface systems. Networkinterface 9385 may provide a direct connection to a remote server via adirect network link to the Internet via a POP (point of presence).Network interface 9385 may provide such connection using wirelesstechniques, including digital cellular telephone connection, CellularDigital Packet Data (CDPD) connection, digital satellite dataconnection, or the like. In some embodiments, one or more sensorsconnect to computing device 9300 wirelessly via network interface 9385.

Many other devices or subsystems (not shown) may be connected in asimilar manner. Conversely, all of the devices shown in FIG. 93 need notbe present to practice the present systems and methods. The devices andsubsystems may be interconnected in different ways from that shown inFIG. 93. The aspect of some operations of a system such as that shown inFIG. 93 are readily known in the art and are not discussed in detail inthis application. Computer instructions to implement the presentdisclosure may be stored in a non-transitory computer-readable mediumsuch as one or more of system memory 9320 or fixed disk 9375. Theoperating system provided on computing device 9300 may be, for example,iOS™, ANDROID™, MS-WINDOWS™, UNIX™, LINUX™, OSX™, or another knownoperating system.

Depending on the embodiment, certain acts, events, or functions of anyof the methods described herein can be performed in a differentsequence, can be added, merged, or left out altogether (e.g., not alldescribed acts or events are necessary for the practice of the method).Moreover, in certain embodiments, acts or events can be performedconcurrently, e.g., through multi-threaded processing, interruptprocessing, or multiple processors or processor cores, rather thansequentially. Moreover, in certain embodiments, acts or events can beperformed on alternate tiers within the architecture. Alternatively, thegaming devices can be organized in alternate communicationconfigurations such as daisy chaining.

The foregoing is a detailed description of some embodiments and aspectsof this specification and is not intended to be limiting. Many otherembodiments are possible and within the skill of those in the art.

We claim:
 1. An automated casino wager gaming credit management systemproviding for a third party casino operator, in combination: inassociation with one or more wager games provide by the casino operator:by a computer system, providing a plurality of individual virtual playerwagering credit accounts; by the computer system, consolidating into asingle win/loss aggregate game period settlement pool all virtual playerwagering account credit used by the plurality of players net of winningsduring a predetermined time game period; and by the computer system,after the completion of a game period, having acquired from the thirdparty casino operator at least a participation interest in at least aportion of one or more receivables associated with the single win/lossaggregate game period settlement pool; and a credit management app inelectronic communication with the computer system through a mobiledevice.
 2. The automated casino wager gaming credit management system ofclaim 1 and further comprising, by the computer system through thecredit management app, displaying a credit limit to a player.
 3. Theautomated casino wager gaming credit management system of claim 1 andfurther comprising, by the computer system through the credit managementapp, offering a player an opportunity to accept a credit processing fee.4. The automated casino wager gaming credit management system of claim 1and further comprising, by the computer system through the creditmanagement app, offering a player an opportunity to determine an amountof credit to be used in a gaming session.
 5. The automated casino wagergaming credit management system of claim 1 and further comprising, bythe computer system through the credit management app, providing adirect interface between the credit management app and a player'sbanking app.
 6. The automated casino wager gaming credit managementsystem of claim 5 wherein the direct interface provides an automatictransfer of funds from the player's bank account to the third partycasino operator.
 7. The automated casino wager gaming credit managementsystem of claim 5 wherein the direct interface provides an automatictransfer of funds won by the player in a gaming session from the thirdparty casino operator to the player's bank account.
 8. The automatedcasino wager gaming credit management system of claim 7 whereinautomatic transfer of funds is limited to any amount of funds by whichthe player's winnings exceed any amount of credit extended to theplayer.
 9. The automated casino wager gaming credit management system ofclaim 1 and further comprising, by the computer system through thecredit management app, displaying a range of credit scores and creditlimits to the player.